Exception Handling

1The Throwable Hierarchy

Everything that can be thrown extends Throwable. Java splits it into two conceptually different branches, and further splits Exception into checked and unchecked.

Throwable
  ├── Error                    — serious, not meant to be caught (OutOfMemoryError, StackOverflowError)
  └── Exception
        ├── RuntimeException    — UNCHECKED (NullPointerException, IllegalArgumentException, ...)
        └── (everything else)   — CHECKED (IOException, SQLException, ...)

try {
    riskyIO();
} catch (java.io.IOException e) {
    // handle it
}

2Checked vs Unchecked — a Compile-Time Distinction

Checked exceptions must be either caught or declared with throws in the method signature — the compiler enforces this. Unchecked exceptions (RuntimeException and its subclasses, plus all Errors) require no such declaration; they can propagate silently through any number of method signatures with no compiler involvement.

void readFile() throws java.io.IOException { // MUST declare — IOException is checked
    java.nio.file.Files.readString(java.nio.file.Path.of("data.txt"));
}

void divide(int a, int b) {
    if (b == 0) throw new ArithmeticException("/ by zero"); // unchecked — no `throws` needed
}

This is a real, intentional Java design decision with no equivalent in JavaScript/TypeScript (where every thrown value is effectively "unchecked" from the type system's point of view) — checked exceptions are meant for conditions a well-behaved caller could reasonably anticipate and recover from (a missing file), while unchecked exceptions signal programming errors (a null reference, an illegal argument) that indicate a bug rather than an expected condition.

3try / catch / finally

try {
    doSomething();
} catch (java.io.FileNotFoundException e) {
    System.out.println("specific: " + e.getMessage());
} catch (java.io.IOException e) {
    System.out.println("more general IO problem: " + e.getMessage());
} finally {
    System.out.println("always runs — cleanup goes here");
}

Catch clauses are checked top to bottom, and the first assignable match wins — so subclasses must be listed before their superclasses, or the more general catch shadows the specific one and the compiler rejects unreachable catch blocks entirely. finally runs whether the try block succeeds, throws, or even executes a return — it is the one block Java guarantees will execute (barring System.exit() or a JVM crash).

4Multi-Catch

When multiple exception types need identical handling, combine them with | instead of duplicating the catch body:

try {
    process();
} catch (java.io.IOException | InterruptedException e) {
    System.out.println("failed: " + e.getMessage());
}

The caught variable's static type is the least upper bound of the listed types, and (unlike separate catch blocks) it is implicitly final — you cannot reassign it.

5try-with-resources

Any object implementing AutoCloseable can be declared in the try(...) parentheses; its close() is called automatically when the block exits, in reverse declaration order, even if an exception was thrown.

try (var reader = new java.io.BufferedReader(new java.io.FileReader("data.txt"))) {
    System.out.println(reader.readLine());
} // reader.close() called automatically here, no finally needed

6Throwing Custom Exceptions and Exception Chaining

class InsufficientFundsException extends Exception {
    InsufficientFundsException(String message, Throwable cause) {
        super(message, cause); // preserves the ORIGINAL exception as the "cause"
    }
}

void withdraw(double amount) throws InsufficientFundsException {
    try {
        // ... some lower-level operation that might throw ...
    } catch (java.sql.SQLException e) {
        throw new InsufficientFundsException("withdrawal failed", e); // chain, don't swallow
    }
}

getCause() retrieves the original exception; printed stack traces show Caused by: chains, which is essential for debugging — swallowing the original exception loses exactly the information you need most.

7Custom Exception Design: Checked or Unchecked?

class ValidationException extends RuntimeException {  // unchecked — a caller bug (bad input)
    ValidationException(String message) { super(message); }
}

class ConfigFileMissingException extends Exception {    // checked — an expected, recoverable condition
    ConfigFileMissingException(String message) { super(message); }
}

Extend RuntimeException for programmer errors and invariant violations; extend Exception directly only when you genuinely want to force callers to handle or explicitly propagate the condition.

⚠️ Common Pitfalls

1. Swallowing exceptions with an empty catch block — catch (Exception e) {} silently discards the failure, turning a debuggable crash into a mysterious later symptom with no trace of the real cause.
2. Catching Exception or Throwable too broadly — masks genuine programming errors (NullPointerException, ArrayIndexOutOfBoundsException) alongside the specific recoverable condition you meant to handle, and can even catch Errors that generally should not be handled at all.
3. A finally block with its own return or throw — unconditionally overrides/discards whatever the try/catch was about to return or throw, silently losing the original outcome; this is legal Java and a genuinely confusing trap.
4. Using exceptions for ordinary, expected control flow — e.g., throwing to signal "not found" in a hot loop — pays the fillInStackTrace() cost (see Under the Hood) for something that isn't exceptional at all; return Optional/a sentinel/a boolean instead.
5. Not closing resources without try-with-resources — a hand-written finally { conn.close(); } is easy to get subtly wrong (e.g., forgetting the null check, or losing the original exception when close() itself throws); try-with-resources handles both correctly by construction.

📋 Quick Reference

try {
    risky();
} catch (SpecificException e) {          // most specific first
    handle(e);
} catch (IOException | SQLException e) { // multi-catch, implicitly final
    handleEither(e);
} finally {
    cleanup(); // always runs
}

try (var res = openResource()) { // AutoCloseable — close() called automatically
    use(res);
}

throw new CustomException("message", causeException); // chain, don't swallow

class MyUnchecked extends RuntimeException { ... } // programmer error, no `throws` needed
class MyChecked extends Exception { ... }            // recoverable, forces `throws` or catch

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

Source: java_exception_handling_theory.md · generated by tools/build_lessons.py