Exceptions: the must-knows

For this sheet, we'll start with the hierarchy and the checked vs unchecked decision, then go under the hood to stack unwinding and its cost, then the exact rules of try, catch, finally and try-with-resources (the home of most output puzzles). After that we cover custom exceptions, lambdas and streams, threads and CompletableFuture, production handling, overriding rules, and the two Errors everyone gets asked about. Every item links to the full lesson. Tick the boxes as you go; your progress is saved.

01Picture it first: the hierarchy decides everything

Think of the hierarchy as the routing table for every rule that follows. Whether the compiler nags you, whether catch (Exception e) catches it, and whether you should catch it at all all depend on which branch a type sits on.

The tree below shows the three zones: Error (red, don't catch), RuntimeException (amber, unchecked, usually a bug or an unrecoverable condition), and the rest of Exception (blue, checked).

Fig. 1

The Throwable hierarchy: Throwable splits into Error, with VirtualMachineError, OutOfMemoryError, StackOverflowError and AssertionError beneath it, and Exception, which splits into RuntimeException with NullPointerException, IllegalArgumentException, IllegalStateException, ClassCastException and ArithmeticException, and checked exceptions such as IOException, SQLException, InterruptedException, TimeoutException and ExecutionException

• Throwable is the root: only Throwable instances can be thrown or caught. It carries a message, a cause, a stack trace and a list of suppressed exceptions. Full lesson
• Error: serious problems the application isn't expected to recover from: OutOfMemoryError, StackOverflowError (both VirtualMachineError), NoClassDefFoundError, ExceptionInInitializerError, AssertionError. Errors are unchecked.
• Exception: conditions a program might reasonably handle. Its subclass RuntimeException (and everything below it) is unchecked; every other Exception subclass is checked.
• Unchecked = RuntimeException + Error: the compiler doesn't force you to catch or declare them. Checked = the rest, including Exception itself. That one sentence answers half the hierarchy questions.
• throw vs throws: throw is the statement that raises an exception object; throws is the method-signature clause that declares checked exceptions the method may let escape.

02Checked vs unchecked: when to use each

The language rule is mechanical. The design question ("which should my exception be?") is where interviewers listen for judgement.

• The textbook rule: use checked exceptions for recoverable conditions the immediate caller can reasonably handle (retry another file, prompt the user), unchecked for programming errors. Full lesson
• The modern practice: most frameworks (Spring, JPA, the java.time and java.util.function APIs) lean unchecked, because checked exceptions leak implementation details through every signature and break lambdas. If the caller three layers up is the only one who can act, a checked exception forces two layers of boilerplate.
• My default: unchecked domain exceptions for business code, checked only at a narrow API where the caller genuinely must decide (and can). Whichever you pick, keep the cause when you convert.

03Under the hood: how a throw unwinds the stack

This is where senior rounds separate people who use exceptions from people who understand them. The mechanism has three steps: create, search, unwind.

• Creating the exception captures the stack: the Throwable constructor calls fillInStackTrace(), which walks every frame of the current thread and records it. That walk is the main cost, and it's proportional to stack depth. The StackTraceElement[] objects are built lazily, only when you call getStackTrace() or print the trace. Full lesson
• The exception table: every compiled method with a try has an exception table in its Code attribute, with rows of from, to, target, type. Entering a try executes no instructions at all, so the happy path is free. On athrow (or an exception the JVM raises, like an NPE), the JVM scans the current method's table in order for a row whose range covers the current instruction and whose type is a supertype of the thrown one.
• Unwinding: if no row matches, the JVM pops the frame (its locals are gone) and repeats the search in the caller, at the instruction that made the call. When a row matches, the operand stack is cleared, the exception is pushed, and execution jumps to the handler. If no frame matches, the thread terminates and its UncaughtExceptionHandler runs.
• How finally is compiled: modern javac copies the finally body onto every exit path (normal completion, each return, each catch), plus a catch-any table row (type = any) that runs the copy and rethrows. The old jsr/ret instructions aren't allowed in class files from Java 7 on.
• Catch order: catch blocks are checked top to bottom, so a subclass must come before its superclass; the reverse is a compile error ("exception has already been caught").

Here's one throw travelling down four frames, checking each frame's table on the way.

Fig. 2

Stack unwinding: parseAmount throws NumberFormatException and fillInStackTrace records four frames; parseAmount has no handler so its frame is popped; charge has a catch for IOException, which doesn't match, so its finally block runs and the frame is popped; handleRequest catches IllegalArgumentException, which matches because NumberFormatException is a subclass, so execution continues there; main is never involved

04try, catch, finally: the exact rules and the output puzzles

This section produces most of the "what does this print?" questions. Learn the table, then do the puzzle.

• finally always runs, except when the JVM stops (System.exit, halt, crash) or the thread never leaves the try (infinite loop, deadlock). That's the complete answer to "does finally always run?". Full lesson
• Never return or throw from finally: both silently replace whatever was happening, including an exception that explained an outage. Most linters flag it.
• Multi-catch (Java 7): catch (IOException | SQLException e) shares one handler. The alternatives can't be subclasses of each other (compile error), and e is implicitly final.
• Precise rethrow (Java 7): in catch (Exception e) { log(e); throw e; }, if e is effectively final, the compiler knows it can only be the checked types the try can throw, so the method declares those, not Exception.
• Unreachable catch: catching a checked exception the try block can't throw is a compile error (Exception and Throwable are exempt, because they also cover unchecked types).

static int a() {
    int x = 1;
    try { return x; }
    finally { x = 2; }
}

static int b() {
    try { return 1; }
    finally { return 2; }
}

static int c() {
    try { throw new IllegalStateException("payment failed"); }
    finally { return 42; }
}

static StringBuilder d() {
    StringBuilder sb = new StringBuilder("a");
    try { return sb; }
    finally { sb.append("b"); }
}

a() returns 1: the value of x was copied into the return slot before finally ran, and changing the local afterwards doesn't touch the copy. b() returns 2, because a return in finally overrides the earlier one. c() returns 42 and the IllegalStateException disappears without a trace, which is why this pattern is dangerous. d() returns a builder containing "ab": the copied value is a reference, and finally mutated the object it points to (the same pass-by-value rule from the Core Java sheet).

05try-with-resources, close order and suppressed exceptions

Try-with-resources (Java 7) is the default for anything with a close() method: streams, JDBC connections, locks wrapped in a resource, HTTP responses. Interviewers ask about it because the old try/finally version had a real bug that this fixed.

• What it needs: any resource implementing AutoCloseable (Closeable is the I/O subinterface whose close throws IOException and should be idempotent). Since Java 9 you can list an existing effectively final variable: try (conn) { ... }. Full lesson
• Close order: resources are closed in reverse order of declaration, and they are closed before any catch or finally block of the same statement runs. A resource that failed to initialise (its expression threw, or it's null) isn't closed.
• Suppressed exceptions: if the body throws and then close() also throws, the body's exception is the one propagated, and the close failure is attached with addSuppressed; read it with getSuppressed(). If only close() throws, its exception is the primary one.
• Why the old way was broken: with manual try/finally, an exception from close() in finally replaced the original exception from the body, so you'd see "stream closed" instead of the real failure.

record Res(String name) implements AutoCloseable {
    Res { System.out.println("open " + name); }
    @Override public void close() {
        System.out.println("close " + name);
        throw new IllegalStateException("close " + name);
    }
}

try (var a = new Res("A"); var b = new Res("B")) {
    throw new RuntimeException("body");
} catch (RuntimeException e) {
    System.out.println("caught " + e.getMessage()
        + ", suppressed " + e.getSuppressed().length);
} finally {
    System.out.println("finally");
}

It prints open A, open B, close B, close A, caught body, suppressed 2, finally. The resources close in reverse order, both close failures are attached to the body's exception instead of replacing it, and the catch runs only after both resources are closed. If you write try/finally by hand instead, an exception thrown by close() in finally replaces body, and the real failure is gone.

06Custom exceptions and the best practices interviewers check

Custom exceptions are where your production habits show. The interviewer is less interested in the class than in what you put in it and where you catch it.

• Extend RuntimeException by default (or Exception if you deliberately want a checked one). Provide a constructor that takes a cause and passes it to super(message, cause). Add fields for the context a handler needs (an order ID, a reason code), never secrets or full card numbers. Full lesson
• Wrap with the cause, always: throw new OrderLookupException(orderId, e) keeps the original trace under "Caused by:". Throwing a new exception without the cause destroys the evidence.
• Don't swallow: an empty catch (or one that only prints) turns an outage into silence. If you really expect and ignore an exception, name the variable ignored and write a comment explaining why.
• Don't log and throw: logging and then rethrowing makes every layer log the same failure, so one error shows up as five stack traces. Either handle it (log and recover) or propagate it, and log once at the boundary that handles it.
• Translate at layer boundaries: the repository turns SQLException into a data-access exception, the service turns that into a domain exception (OrderNotFoundException), the web layer turns that into an HTTP 404. Each layer speaks its own language, with the cause chained underneath.
• Don't use exceptions for control flow: expected outcomes like "not found" on a lookup are often better as Optional or a result type; reserve exceptions for the exceptional path.
• InterruptedException is special: if you catch it and can't propagate it, restore the flag with Thread.currentThread().interrupt(), otherwise code higher up never learns the thread was asked to stop.

Here's a custom exception and a translation at a boundary, the way I'd write them:

public class PaymentUnavailableException extends RuntimeException {
    private final String orderId;

    public PaymentUnavailableException(String orderId, Throwable cause) {
        super("Payment provider unavailable for order " + orderId, cause);
        this.orderId = orderId;
    }

    public String orderId() { return orderId; }
}

// in the payment service: translate the vendor's exception, keep the cause
public Receipt charge(String orderId, Money amount) {
    try {
        return gateway.charge(orderId, amount);
    } catch (GatewayTimeoutException e) {
        throw new PaymentUnavailableException(orderId, e);   // no logging here
    }
}

Notice three things. The constructor takes the cause, so the gateway's stack trace survives as "Caused by:". The service doesn't log, because the global handler will log it once with the request context. And the message carries the order ID (useful for support) but not the card details.

07Exceptions in lambdas and streams

This comes up as soon as the interviewer sees you write a stream. The functional interfaces in java.util.function (Function, Consumer, Supplier) don't declare any checked exceptions, so a lambda body can't throw one.

• The compile error: paths.stream().map(Files::readString) doesn't compile, because readString throws IOException and Function.apply doesn't declare it. Full lesson
• The standard fix: catch inside the lambda and wrap in an unchecked exception, usually UncheckedIOException (Java 8) for I/O, then unwrap at the boundary if a caller needs the original.
• Other options: write your own functional interface with a throws clause (ThrowingFunction<T, R, E extends Exception>), or use a plain for loop when the checked exception matters. "Sneaky throw" tricks that hide a checked exception from the compiler work, but they surprise every reader.
• What a stream does on failure: an exception thrown by any stage stops the pipeline and propagates out of the terminal operation; elements after the failure aren't processed. In a parallel stream, the exception is rethrown in the calling thread, and other subtasks may still be running briefly when it arrives.

List<String> bodies = paths.stream()
    .map(p -> {
        try {
            return Files.readString(p);
        } catch (IOException e) {
            throw new UncheckedIOException("Failed to read " + p, e);
        }
    })
    .toList();

08Exceptions in threads, executors and CompletableFuture

This is the most common senior follow-up, because it's where exceptions silently disappear in real systems. An exception unwinds only its own thread's stack: it never jumps to the thread that started the work.

• Plain threads: an uncaught exception terminates that thread only. The JVM calls the thread's UncaughtExceptionHandler, then its ThreadGroup, then the default handler set with Thread.setDefaultUncaughtExceptionHandler; with none set, the trace is printed to System.err. The main thread and others keep running.
• ExecutorService.execute(runnable): the exception reaches the worker thread's uncaught handler (so it's printed), the worker dies, and the pool replaces it.
• ExecutorService.submit(task): the exception is captured in the returned Future and nothing is printed. You only see it when you call future.get(), which throws ExecutionException with the original as getCause(). Never calling get() means never seeing the failure.
• ScheduledExecutorService.scheduleAtFixedRate: if one run throws, all later runs are silently cancelled. Wrap the task body in try/catch and log.
• CompletableFuture: exceptionally(ex -> fallback) recovers with a value; handle((value, ex) -> ...) always runs and can transform success or failure; whenComplete observes without changing the result. join() throws unchecked CompletionException, get() throws checked ExecutionException, and the throwable your callback receives is often wrapped in CompletionException, so unwrap getCause(). Module 05: Multithreading

ExecutorService pool = Executors.newFixedThreadPool(2);

pool.execute(() -> { throw new IllegalStateException("A"); });
Future<?> f = pool.submit(() -> { throw new IllegalStateException("B"); });
CompletableFuture<String> cf = CompletableFuture
    .supplyAsync(() -> { throw new IllegalStateException("C"); });

try {
    f.get();
} catch (ExecutionException e) {
    System.out.println("B via get: " + e.getCause().getMessage());
} catch (InterruptedException e) {
    Thread.currentThread().interrupt();
}

String result = cf
    .handle((value, ex) -> ex == null ? value : "fallback after " + ex.getCause().getMessage())
    .join();

Only "A" is printed automatically, by the default uncaught exception handler of the worker thread. "B" is invisible until f.get() throws ExecutionException, and "C" is invisible until a stage looks at it: here handle receives a CompletionException whose cause is the IllegalStateException, so result is "fallback after C". Remove the get() and the handle, and two of three failures vanish without a log line.

09Production handling: global handlers, error codes, retries and idempotency

In system-flavoured Java interviews, "how do you handle exceptions in your service?" is really a question about boundaries. Here's the shape I'd describe.

• One global handler per entry point: in a web app, a single @RestControllerAdvice (Spring) or exception mapper maps exception types to HTTP statuses and a consistent body, logs once with the request or trace ID, and never leaks stack traces to clients. Spring 6 ships a ProblemDetail type for the RFC 9457 (formerly RFC 7807) problem format. Full lesson
• Stable error codes: return a machine-readable code (PAYMENT_DECLINED, ORDER_NOT_FOUND) plus a human message. Clients branch on the code; the message can change.
• Status mapping: validation and domain rule failures become 4xx (400, 404, 409, 422) and are logged at WARN or lower; unexpected failures become 500 and are logged at ERROR with the full trace. Alert on 5xx rate, not on every 4xx.
• Retry only transient failures: timeouts, connection resets, 503 and 429 are worth retrying; a 400 or a validation error will fail the same way every time. Use exponential backoff with jitter (for example 100 ms, 200 ms, 400 ms, plus random spread) and cap attempts at around 3, so a struggling dependency isn't hit by a retry storm.
• Retries need idempotency: a timed-out "charge card" call may have succeeded on the server. Send an idempotency key with the request so the server can return the original result instead of charging twice; only retry non-idempotent operations when that protection exists.
• Fail fast on Errors: after an OutOfMemoryError, the process may be in an inconsistent state. Run with -XX:+HeapDumpOnOutOfMemoryError and -XX:+ExitOnOutOfMemoryError so the orchestrator restarts a clean instance and you keep the evidence.

Here's the shape of a retry with the two rules built in: retry only what's transient, and reuse one idempotency key across attempts.

Receipt chargeWithRetry(ChargeRequest req) throws InterruptedException {
    String idempotencyKey = req.orderId();          // same key on every attempt
    long backoffMs = 100;
    for (int attempt = 1; ; attempt++) {
        try {
            return gateway.charge(req, idempotencyKey);
        } catch (GatewayTimeoutException | ServiceUnavailableException e) {
            if (attempt == 3) throw new PaymentUnavailableException(req.orderId(), e);
            Thread.sleep(backoffMs + ThreadLocalRandom.current().nextLong(backoffMs));
            backoffMs *= 2;
        }
        // CardDeclinedException is not caught: retrying a decline can't succeed
    }
}

10Overriding rules for throws, and the two Errors everyone asks about

Two short topics close the sheet. Both are quick to state and easy to get backwards under pressure.

• Overriding and throws: an overriding method may declare the same, fewer or narrower checked exceptions, or none, and any unchecked exceptions it likes. It may not add a new or broader checked exception, because code written against the parent type wouldn't be prepared for it. The same rule applies when implementing an interface method. Full lesson
• Constructors are the reverse case: a subclass constructor must declare (at least) the checked exceptions its super(...) call can throw, because it can't wrap super(...) in a try.
• StackOverflowError: the current thread's stack is full, almost always from unbounded or very deep recursion (a classic is toString or hashCode recursing through a bidirectional JPA relationship). The default thread stack (-Xss) is typically 1 MB on 64-bit Linux and macOS, enough for roughly 10,000 to 20,000 simple frames; it depends on frame size. The stack unwinds when it's thrown, so the JVM is usually healthy afterwards, but fix the recursion rather than catching it.
• OutOfMemoryError: an allocation failed after the GC couldn't free enough space. The message tells you which region: Java heap space, Metaspace (too many classes, often a class loader leak), unable to create native thread (thread or OS limits), Direct buffer memory, Requested array size exceeds VM limit, or GC overhead limit exceeded (Parallel GC spending over 98% of time in GC while recovering under 2% of the heap). Any thread can be the one that hits it, often not the one leaking. Java memory management

11How to say it in the interview

When I ask about exceptions, I'm listening for four things: that you know checked vs unchecked is defined by the hierarchy (RuntimeException and Error) and you have an opinion on when to use each; that you can explain unwinding and why stack traces cost something; that you know the finally and try-with-resources edge cases without guessing; and that you've handled failures in async code, where they get lost. Senior candidates volunteer the boundary rules (wrap with the cause, translate per layer, log once) and connect retries to idempotency without being prompted.

Here's how this might look if you sketch it on the whiteboard:

Interview questions for this topicComing soon