Exceptions — Handling What Goes Wrong

You've already seen programs crash — a NullPointerException, an ArithmeticException, a bad parse. An exception is Java's mechanism for signaling "something went wrong" and transferring control to code that can deal with it, instead of returning error codes that callers forget to check. The defining design choice is the split between checked exceptions — recoverable conditions the compiler forces you to handle or declare — and unchecked ones (RuntimeException), which signal programming bugs and carry no such requirement. Around that split sit try/catch to recover, throw/throws to raise and declare, finally to always clean up, and try-with-resources to close things automatically.

Every output below was produced by compiling and running the code.

Table of contents

1. try/catch: recover instead of crash
2. The hierarchy: checked vs unchecked
3. throw, throws, and custom exceptions
4. finally: cleanup that always runs
5. try-with-resources
6. Mental-model summary
7. Gotcha checklist

1. try/catch: recover instead of crash

Wrap risky code in a try; if it throws, control jumps to a matching catch, which handles the problem so the program continues instead of dying.

Output:

parsed: 42
bad input: oops
parsed: 7
done

Analysis. parseInt("oops") threw a NumberFormatException; instead of crashing the program (as it did back in Tutorial 5), the catch handled it — printed bad input: oops — and the loop carried on to "7". The exception transferred control from the failing parseInt straight to the catch, skipping the println("parsed: ...") for that iteration. One bad input no longer sinks the whole program.

Intuition. Mechanism. When code in a try throws, the JVM abandons the rest of the try block and looks for a catch whose type matches the exception (here NumberFormatException). If one matches, its body runs and execution continues after the whole try/catch. The thrown object (e) carries details — a message, a stack trace.

Concrete bite. The win is targeted recovery: only the operations that can fail are guarded, and the handler decides what "recover" means (skip, retry, default). Catch too broadly (catch (Exception e)) and you may swallow bugs you'd rather see; catch the specific type and unexpected exceptions still propagate.

2. The hierarchy: checked vs unchecked

Every exception is a Throwable. The tree splits into Error (serious JVM problems you don't catch) and Exception. Within Exception, the subclass RuntimeException and its descendants are unchecked; everything else under Exception is checked. The difference is a compiler rule: checked exceptions must be caught or declared.

An unchecked exception (a RuntimeException like ArithmeticException) needs no declaration — code compiles and only fails at run time if it actually throws:

Output (prints 5, then crashes):

5
Exception in thread "main" java.lang.ArithmeticException: / by zero

Analysis. divide can throw ArithmeticException, but as an unchecked exception it required no throws and no try — the code compiled freely, ran divide(10, 2) fine (5), then threw on divide(10, 0). Unchecked exceptions represent bugs (a zero divisor, a null dereference, a bad index) the compiler doesn't force you to anticipate everywhere.

Intuition. Mechanism. The compiler tracks checked exceptions (subclasses of Exception but not RuntimeException): any code that can throw one must either catch it or declare it with throws. RuntimeExceptions and Errors are exempt — they could occur almost anywhere, so requiring declarations would be unbearable.

Concrete bite. Call something that throws a checked exception without handling it and the compiler refuses:

Compiler error:

Main.java:7: error: unreported exception IOException; must be caught or declared to be thrown
        risky();
             ^

IOException is checked, so calling risky() without a try/catch (or a throws on main) won't compile — "unreported exception … must be caught or declared." Wrapping the call fixes it: try { risky(); } catch (IOException e) { … }.

3. throw, throws, and custom exceptions

You raise an exception with throw, declare that a method may raise a checked one with throws, and define your own exception by extending Exception (checked) or RuntimeException (unchecked). A custom type names the failure and carries its data.

Output:

balance: 50
denied: need 100, have 50

Analysis. withdraw(50) succeeded (balance 50); withdraw(100) saw amount > balance and throw-ed an InsufficientFundsException, which unwound out of withdraw to the catch, printing the message it carried. InsufficientFundsException extends Exception, so it's checked — that's why withdraw declares throws InsufficientFundsException and the caller must handle it. The custom type makes the failure a named, catchable thing with its own data.

Intuition. Mechanism. throw creates a control transfer: it stops the current method and propagates the exception up the call stack until a matching catch is found (or the program ends). throws declares that propagation in the signature. Extending Exception vs RuntimeException chooses checked vs unchecked for your type.

Concrete bite. A custom exception beats a generic one (throw new Exception("...")): callers can catch (InsufficientFundsException e) specifically, distinguish it from other failures, and the type itself documents the condition. The message (super(msg)) and any extra fields travel with it to the handler.

4. finally: cleanup that always runs

A finally block attached to a try runs no matter how the try exits — normal completion, a caught exception, or even a return. It's where cleanup that must always happen goes.

Output:

finally ran
from try

Analysis. Read the order: process() hit return "from try", but the finally ran before the method actually returned — so finally ran printed first, then the returned value. finally intercepts every exit path, including a return in the middle of the try. That's exactly what makes it reliable for cleanup.

Intuition. Mechanism. The JVM guarantees finally executes on the way out of the try, whatever caused the exit — completion, exception, or return (the return value is computed, then finally runs, then control leaves). Only a JVM halt (System.exit) or power loss skips it.

Concrete bite. The finally ran-before-from try order is the surprise: people expect a return to leave immediately. It doesn't — finally always gets its turn first, which is the whole point (release the lock, close the file, even if you bailed early). The trap to avoid is returning from finally, which silently discards the try's exception or value.

5. try-with-resources

Closing resources by hand in finally is verbose and easy to get wrong. try-with-resources declares a resource in parentheses after try; any object implementing AutoCloseable is closed automatically when the block exits, in reverse order of opening.

Output:

open file
use file
close file
after

Analysis. The resource opened, was used, and then close() ran automatically as the try block exited — before after printed — with no explicit finally. Had use() thrown, close() would still have run. try-with-resources is finally-based cleanup specialized for anything AutoCloseable (files, streams, connections, locks), generated correctly for you.

Intuition. Mechanism. The compiler expands try (R r = ...) into a try/finally that calls r.close() on exit, handling the edge cases (closing even if the body throws, suppressing secondary exceptions from close). Any AutoCloseable qualifies, so the same syntax works for every resource type.

Concrete bite. The alternative — a manual finally { r.close(); } — is where leaks hide: forget it, get the ordering wrong, or let close() itself throw and mask the real error, and a file handle or connection leaks. try-with-resources removes that whole class of bug by construction; the close is not optional and not yours to forget.

6. Mental-model summary

7. Gotcha checklist

Your Turn

Before you move on, check your understanding with the coach — explain the idea, apply it, weigh the trade-offs, then defend your reasoning.