How exceptions work in Java

For this lesson, we'll focus on what actually happens between throw and catch: the Throwable family tree, the exception table that javac writes into every method, how the JVM unwinds the stack, the exact rules of finally, and why creating an exception costs more than throwing it. Interviewers love this topic because everyone has written try/catch, but very few candidates can say what the bytecode looks like or why a return inside finally is a bug.

01Picture it first: a fire alarm going up the floors of a building

Think of the call stack as a building where each floor is a method call. When something catches fire on the 5th floor (throw), that floor checks its own list of fire wardens (its exception table). If it has a warden trained for this kind of fire, the warden handles it and the floor keeps working. If not, everyone on the floor leaves (the frame is popped, finally blocks run on the way out) and the alarm moves down to the 4th floor. That repeats until a warden is found or the building (the thread) is empty.

Before we follow the alarm, let's get the family tree right. The diagram below shows the three branches of Throwable and which ones the compiler forces you to handle.

Fig. 1

The Throwable hierarchy: Throwable splits into Error and Exception; Error holds unchecked JVM problems like OutOfMemoryError and StackOverflowError; Exception holds checked exceptions like IOException and SQLException, plus RuntimeException, the unchecked branch containing NullPointerException and IllegalArgumentException

Notice that "checked" is purely a compiler idea. The JVM treats every Throwable the same way, which is a fact we'll lean on in the next lesson.

02Under the hood: what javac writes for try, catch and finally

static int charge(int cents) {
    try {
        return pay(cents);
    } catch (IllegalStateException e) {
        return -1;
    } finally {
        audit();
    }
}

Here's the real output of javap -c for that method, compiled with javac --release 21: