Exception handling in production: the complete guide

Interviewers love this topic because it sits right where syntax meets judgement. Anyone can write a catch block. Fewer people can say which layer should catch, whether to retry, what status code the client sees, what gets logged and how often, and what happens to the interrupt flag. Every one of those questions has an incident behind it, so your answers tell the interviewer very quickly whether you've owned a service on call.

For this lesson, we'll build the whole picture in one place: a fast refresher on the mechanics, eight habits that keep production quiet, a way to classify any failure by who can fix it, translating exceptions to HTTP at one boundary, retries done properly, the resilience patterns around them, and the edge cases senior rounds probe (async code, transactions, finally, testing, cost). We'll keep it generic Java 21 and Spring-style code you can use anywhere.

01Picture it first: the waiter and the empty egg tray

Think of a waiter taking your breakfast order. Most mornings it's routine: order in, plate out. Today the kitchen is out of eggs. The waiter has three honest options. If a substitute is fine, he handles it right there ("scrambled tofu instead?"). If it's a decision above his pay grade, he passes it up to the manager. And if the stove is on fire, nobody at the table can fix that: he gets everyone out and calls the fire brigade.

An exception is the waiter walking away from the normal path. throw means "I can't carry on normally, here's what went wrong". Each method up the call stack gets a chance to handle it, exactly like the waiter's chain of command. What he must never do is shrug, say nothing, and bring you an empty plate. That's the swallowed exception, and it's the most expensive bug in this lesson.

Here's what the JVM actually does when a method throws: it pops frames one by one, running any finally on the way, until it finds a catch whose type matches.

Fig. 1

From throw to catch: parse() throws, its frame is popped, load()'s finally runs, and handle()'s matching catch resumes execution; main() never sees the exception

Notice three things. The catch happens in the closest frame with a matching type, not the most sensible one, so where you put your catch blocks is a design decision. finally runs during unwinding, which is why cleanup belongs there (or better, in try-with-resources). And if nothing matches, the thread dies, which in a server usually means one request fails and in a background worker can mean the work silently stops.

02The foundations in ten minutes

You probably know the syntax. Let's make sure the details that interviewers poke at are solid, because the production habits build on them.

throw, try, catch, finally

Here's how I'd write it:

public String readConfig(Path path) {
    try {
        return Files.readString(path);
    } catch (NoSuchFileException e) {                    // specific first
        log.info("No config at {}, using defaults", path);
        return DEFAULT_CONFIG;
    } catch (IOException e) {                            // then the general parent
        throw new UncheckedIOException("Could not read config " + path, e);
    } finally {
        log.debug("Config lookup finished for {}", path);
    }
}

Notice:

• Catch order matters. Java tries the catch clauses top to bottom and takes the first match. NoSuchFileException is a subclass of IOException, so if you swap them the compiler rejects the code: "exception NoSuchFileException has already been caught".
• The missing file is expected, so it's handled at INFO and returns a value. Every other IOException is not, so it's translated into UncheckedIOException with e as the cause.
• finally runs on every path: the normal return, the handled miss, and the rethrow.

Multi-catch (Java 7+) gives several unrelated types the same handling:

public Quote parseQuote(String body) {
    try {
        return mapper.readValue(body, Quote.class);          // Quote's constructor parses dates
    } catch (JsonProcessingException | DateTimeParseException e) {
        throw new MalformedResponseException("Unreadable quote from pricing", e);
    }
}

The variable e is implicitly final, and its static type is the closest common supertype (Exception here, since one is checked and one isn't). The alternatives can't be subclasses of each other: catch (IOException | FileNotFoundException e) is a compile error, because the second one is already covered.

The Throwable family tree

Everything you can throw extends Throwable, and the tree has three branches that production code treats very differently.

Fig. 2

The Throwable family: Error (don't catch, let the process restart), checked Exception (catch where you have context and translate) and RuntimeException (a bug to fix or a rule to map to 4xx)

• Error (OutOfMemoryError, StackOverflowError, NoClassDefFoundError) means the JVM or its environment is broken. It's unchecked, and you almost never catch it.
• Checked exceptions (IOException, SQLException, InterruptedException) are everything under Exception that isn't a RuntimeException. The compiler forces you to catch them or declare them with throws.
• RuntimeException (NullPointerException, IllegalArgumentException, IllegalStateException) is unchecked. It usually signals a bug, or a rule the caller broke.

The checked versus unchecked split is a compile-time rule only. At runtime the JVM treats every Throwable identically. We go deep on that in Checked vs unchecked exceptions.

Wrapping with a cause, and suppressed exceptions

When you catch a low-level exception and throw a more meaningful one, you pass the original as the cause. That builds a chain, like Russian dolls: each exception holds the one that caused it. A second, separate mechanism, suppressed exceptions, records failures that happened while you were already failing, typically in close().

Fig. 3

Left: a cause chain where ReportImportException wraps DataAccessException which wraps the root SQLException; right: a primary ParseException with an IOException from close() attached as suppressed; below, the Caused by and Suppressed lines each produces in a log

try {
    rows.forEach(repository::insert);
} catch (DataAccessException e) {
    throw new ReportImportException("Import of report " + reportId + " failed", e);  // e is the cause
}

The difference matters when you read logs. Caused by: answers why this failed: walk it with getCause() until you hit the root. Suppressed: answers what else went wrong during cleanup, and you read it with getSuppressed(). try-with-resources adds suppressed exceptions for you; when you collect failures from parallel workers you can do it by hand:

List<Throwable> failures = collectFailures(futures);       // from Future.get() calls
if (!failures.isEmpty()) {
    var batch = new BatchFailedException(failures.size() + " of " + futures.size() + " shards failed",
                                         failures.getFirst());               // first one is the cause
    failures.stream().skip(1).forEach(batch::addSuppressed);                 // nothing gets lost
    throw batch;
}

Making your own exception

A custom exception earns its place when a caller or a handler will treat it differently from everything else. Give it a name that says what went wrong, the constructors you need, and fields for the data a handler will read:

public class DependencyUnavailableException extends RuntimeException {
    private final String dependency;

    public DependencyUnavailableException(String dependency, Throwable cause) {
        super("Dependency '%s' is unavailable".formatted(dependency), cause);
        this.dependency = dependency;
    }

    public String dependency() { return dependency; }
}

How to design a whole hierarchy of these, with error codes and a retryable flag, is the subject of Custom exceptions and best practices.

03Eight habits that keep production quiet

These are the rules I'd want on the wall of any Java team. None of them is clever. All of them come from incidents.

1. Never swallow an exception silently

// ❌ the failure vanishes; nobody will ever know this line ran
try { publishEvent(order); } catch (Exception e) { }

// ✅ ignoring is the right call here, and the comment says why
try {
    Files.delete(tempFile);
} catch (NoSuchFileException e) {
    // Already gone, which is the state we wanted.
}

An empty catch is sometimes correct, but only for a specific type, with a comment that proves you thought about it. A bare catch (Exception e) {} also eats NullPointerException, IllegalStateException and every bug you'll write next year.