Java Exception Handling: Checked vs Unchecked, try-with-resources, and Real Patterns

Exception handling is where codebases quietly reveal their quality. Good error paths make failures diagnosable in minutes; bad ones — swallowed exceptions, logs full of stack traces nobody reads, catch (Exception e) {} — turn every incident into archaeology.

Java’s exception system is more opinionated than most languages’: it forces you to acknowledge certain failures at compile time. That design is controversial, half-abandoned by modern frameworks, and still worth understanding deeply — because you’ll live inside it either way.

The Mechanics: throw, try, catch, finally

An exception is an object (extending Throwable) that abandons normal control flow when thrown, unwinding the call stack until something catches it:

public long withdraw(long paise) {
    if (paise > balance) {
        throw new IllegalStateException(
            "Insufficient funds: requested " + paise + ", balance " + balance);
    }
    balance -= paise;
    return balance;
}

Catching:

try {
    account.withdraw(50_000);
    receiptPrinter.print(account);          // skipped if withdraw throws
} catch (IllegalStateException e) {
    ui.showError(e.getMessage());
} finally {
    audit.log("withdraw-attempt");          // runs on success AND failure
}

Rules that matter:

Control jumps at the throw point; the rest of the try block never runs.
Multiple catch blocks are checked top-down, first match wins — so order subtypes before supertypes (catch (FileNotFoundException e) before catch (IOException e); the compiler enforces this).
One block for several unrelated types: catch (SQLException | IOException e).
finally runs no matter what — exception, return, even a break. Its historical job, closing resources, has been superseded (next section), but it survives for cleanup like unlocking or metric timers.
An uncaught exception propagates up the entire stack; if main doesn’t catch it, the thread dies with the stack trace you know well.

The stack trace, incidentally, is the single most valuable debugging artifact Java produces — read it top-down: first line is what and where, following at lines are the call path, and any Caused by: sections are the underlying root cause. Learning to read one carefully beats an hour of speculation.

The Hierarchy and the Big Split

Throwable
├── Error                    ← JVM-level disasters: OutOfMemoryError, StackOverflowError
│                              Don't catch these. You can't fix them from inside.
└── Exception
    ├── (checked)            ← IOException, SQLException, InterruptedException...
    │                          Compiler FORCES callers to catch or declare
    └── RuntimeException     ← unchecked: NullPointerException, IllegalArgumentException,
                               IndexOutOfBoundsException, ClassCastException...

Checked exceptions represent anticipated environmental failures — file missing, network down, database unreachable. A method that can throw one must declare it, and callers must deal with it or redeclare it:

public Config load(Path path) throws IOException {
    return parse(Files.readString(path));
}

Unchecked exceptions (RuntimeException subclasses) represent bugs — null where an object was promised, index off the end, argument violating a precondition. The compiler doesn’t force handling, because the correct “handler” is fixing the code.

That’s the theory, and as a decision rule for throwing it holds up: caller can plausibly recover → checked; programming error → unchecked. The practice is messier: checked exceptions compose badly with lambdas and streams (none of the functional interfaces declare them), and forcing every caller to ceremony-catch things they can’t fix produced decades of empty catch blocks. Modern frameworks (Spring, Hibernate) wrap checked exceptions into unchecked ones wholesale, and newer JVM languages dropped checked exceptions entirely. The pragmatic modern stance: throw unchecked by default in application code, reserve checked for cases where every caller genuinely has a recovery move, and always preserve the cause when translating (below).

try-with-resources: The Only Way to Close Things

Before Java 7, closing files/connections correctly required a finally dance that nearly everyone got subtly wrong (close can itself throw; multiple resources need nesting). try-with-resources fixed it:

try (var in  = Files.newBufferedReader(source);
     var out = Files.newBufferedWriter(target)) {
    in.lines().forEach(line -> writeLine(out, line));
}   // both closed automatically, in REVERSE order, even on exception

Anything implementing AutoCloseable qualifies — streams, readers, JDBC connections, HTTP clients, locks via wrappers. Fine print worth knowing: if the body throws and a close also throws, the body’s exception wins and the close failure is attached as a suppressed exception (visible in the stack trace, retrievable via getSuppressed()) — so no failure is silently lost.

Rule with no exceptions: acquiring a closeable resource? try-with-resources. Manual close() in finally in new code is a review comment waiting to happen.

Designing Exceptions: Messages, Chaining, Custom Types

Messages are for the 3 a.m. reader

// useless at 3 a.m.
throw new IllegalArgumentException("Invalid input");

// diagnosable
throw new IllegalArgumentException(
    "Order quantity must be 1..%d, got %d (sku=%s)".formatted(MAX_QTY, qty, sku));

Include what was expected, what was received, and identifying context. The person reading this message will not have your mental state; very possibly it will be you, next year.

Chaining: never destroy the root cause

When translating a low-level exception into a domain-level one, pass the original as the cause:

try {
    return repository.findOrder(id);
} catch (SQLException e) {
    throw new OrderLookupException("Failed to load order " + id, e);   // ← the 'e' matters
}

The stack trace then shows both layers via Caused by:. Omitting the cause — throw new OrderLookupException("failed") — is one of the most damaging habits in Java: the actual reason (connection timeout? bad SQL? constraint violation?) is gone forever. Same rule when logging-and-rethrowing is replaced by wrap-and-rethrow: exactly one layer should ultimately log it, with the full chain intact.

Custom exceptions: fewer than you think

public class PaymentDeclinedException extends RuntimeException {
    private final String declineCode;

    public PaymentDeclinedException(String declineCode, String message, Throwable cause) {
        super(message, cause);
        this.declineCode = declineCode;
    }
    public String declineCode() { return declineCode; }
}

Create a custom type when callers will catch it specifically or when it carries structured data (a decline code, a retry-after hint). Don’t mirror every service with a FooServiceException reflexively — a custom exception nobody catches by type is just RuntimeException with extra steps. And prefer the standard vocabulary where it fits: IllegalArgumentException (bad input), IllegalStateException (right input, wrong time), UnsupportedOperationException, NoSuchElementException — every Java developer already knows what they mean.

The Antipattern Gallery

Each of these appears in real codebases weekly:

1. The swallow. The worst one:

try { process(order); } catch (Exception e) { }   // failure erased from history

The system misbehaves with no evidence. If a failure is genuinely ignorable (it almost never is), say so: catch the narrowest type and comment why. Minimum acceptable: log it.

2. Catch-log-rethrow at every layer. One failure → five stack traces in the log → on-call engineer chasing “five errors” that are one. Handle or propagate; log once, at the boundary that handles it.

3. catch (Exception e) far too broad. It catches your NullPointerException bug and dresses it up as “payment service unavailable.” Catch the specific types you can actually handle; let bugs crash loudly to the top-level handler.

4. Exceptions as control flow:

try { return Integer.parseInt(s); } catch (NumberFormatException e) { return 0; }

This one’s borderline-acceptable only because the JDK gives no tryParse — but never design your own APIs this way. Exception construction captures the whole stack trace, ~1000× the cost of an if; and semantically, expected outcomes aren’t exceptional. Offer a checking method (canHandle()) or return Optional.

5. Throwing raw Exception/Throwable. Declares nothing, forces callers into broad catches, spreads virally through signatures.

Where Exceptions Should Actually Be Handled

The most useful design guidance in this whole topic: most code should not catch anything. A well-shaped application handles errors at a few deliberate boundaries:

HTTP request ─▶ Controller ─▶ Service ─▶ Repository
                   ▲              │           │
                   │              └── throws ─┘   (business & infrastructure code
              global exception                     mostly just lets it fly)
              handler: maps exception → status code + logged incident

Framework examples: Spring’s @ControllerAdvice, a message consumer’s retry/dead-letter wrapper, a CLI’s top-level try in main. Between the throw site and that boundary, code stays clean — no try/catch noise — because propagation is handling. You add a local catch only when you can do something meaningful: retry with backoff, substitute a fallback value, convert to a domain result type, or add crucial context via wrap-and-rethrow.

A final production habit: make peace with InterruptedException. If you catch it (from sleep, join, blocking queues), either rethrow it or restore the flag — Thread.currentThread().interrupt(); — never swallow it; thread-pool shutdown depends on it. (More in the concurrency guide.)

Exceptions Meet Modern Java: Streams, Results, and Pattern Matching

Two friction points and one emerging alternative worth knowing about.

Checked exceptions inside lambdas. Files.readString throws IOException; map() takes a Function that declares nothing. The result is the ugliest idiom in modern Java:

paths.stream().map(p -> {
    try { return Files.readString(p); }
    catch (IOException e) { throw new UncheckedIOException(e); }
}).toList();

The standard moves: wrap into an unchecked exception (as above — UncheckedIOException exists precisely for this), extract a helper method that does the wrapping once, or restructure so the IO happens in a plain loop and only the pure transformation streams. There is no elegant fourth option; this seam is the strongest practical argument against checked exceptions in new API design.

Result types as an alternative. For expected failures — validation, parsing user input, business rule rejections — many teams now return a value instead of throwing: Optional<T> when the caller just needs presence/absence, or a small sealed result type when the failure carries information:

sealed interface ParseResult permits Parsed, Malformed {}
record Parsed(Config config) implements ParseResult {}
record Malformed(int line, String issue) implements ParseResult {}

Callers handle both cases in an exhaustive switch — the compiler enforces that the failure path is considered, which a catch block never quite achieves (you can always just… not catch). The working division: result types for outcomes you expect and route on; exceptions for failures that abandon the operation. A payment being declined is an outcome. The payment gateway being unreachable is an exception.

Frequently Asked Questions

Does try/catch slow my code down? Entering a try block costs essentially nothing on modern JVMs — the tables are built at compile time. What costs is throwing: constructing the exception captures the full stack trace, which is why exceptions-as-control-flow is a performance issue as well as a design one.

Should I catch Error or Throwable ever? Almost never. A rare legitimate case is a top-level boundary in long-running worker frameworks that logs absolutely everything before letting the thread die. OutOfMemoryError and friends leave the JVM in a state where “handling” is mostly fiction — see the memory guide.

Where do exception messages end up — can users see them? Assume yes eventually, via logs at minimum. So: no secrets, no internal hostnames if logs are shared, and definitely no user passwords in messages. Conversely, messages shown to end users should come from your boundary layer’s mapping, not raw e.getMessage() — “ORA-00942: table or view does not exist” is not a user experience.

What is a stack trace’s ... 23 more line? Trimming: frames in a Caused by: section that duplicate the enclosing trace’s frames are elided. The information is still all there — read each Caused by: from its top.

Self-Check

A catch (IOException e) block sits above catch (FileNotFoundException e). What does the compiler say, and why?
In try-with-resources, the body throws A and close() throws B. What propagates, and where did the other go?
Why is throw new ServiceException("db failed") inside a catch (SQLException e) block a bug even though it compiles and “works”?
Your service calls a flaky API. Where do the retry logic and the final error logging each belong — call site, service layer, or boundary — and why not both everywhere?
When is IllegalStateException the right choice over IllegalArgumentException?

(Answers: unreachable code error — FileNotFoundException is a subtype, so it must come first. A propagates; B rides along as a suppressed exception. The root cause e was discarded — chain it as the constructor’s cause. Retry near the call (it’s a recovery move needing local context); logging once at the boundary — duplicated logging multiplies noise, duplicated retries multiply load. When the argument is fine but the object’s current state makes the operation invalid — selling from an empty inventory, shipping an unconfirmed order.)

Next: Generics — the type-system machinery behind List<T>, bounded wildcards, PECS, and why erasure makes some things impossible.