How Is Java's Exception Hierarchy Organized?

Everything throwable in Java descends from java.lang.Throwable, which has two direct subclasses and therefore two separate branches.

Exception is the branch for conditions a program can reasonably be expected to handle. It splits again. Its unchecked branch is RuntimeException, which holds NullPointerException, IllegalArgumentException, IllegalStateException, IndexOutOfBoundsException, ArithmeticException, ClassCastException and the rest — the errors that indicate a bug in the program rather than an expected external failure. Its checked branch holds everything else that extends Exception but not RuntimeException: IOException, SQLException, ParseException, ClassNotFoundException. These represent conditions outside your control, such as a file being absent or a network being down, and the compiler forces you to acknowledge them.

Error is the branch for problems the JVM itself cannot recover from: OutOfMemoryError, StackOverflowError, InternalError, NoClassDefFoundError. These are not about your logic. The JVM throws them when it cannot continue, and the only reasonable responses are to let the process die so a supervisor restarts it, or to free resources and try to carry on.

The design intent is that a catch clause for Exception means "I handle failures that are part of normal operation", while the absence of RuntimeException under Exception means that the unchecked branch deliberately does not force the caller to write boilerplate for what are almost always programming mistakes.

The three differ in what they represent and in who is expected to handle them. A RuntimeException is an unchecked exception signalling a bug or a misuse of an API — a null reference, an out-of-range index, an illegal argument. The compiler does not require you to catch it, and catching it broadly is usually wrong, because the correct response is to fix the code.

An Exception that is not a RuntimeException is a checked exception signalling an expected external failure — a file that is not there, a socket that closed, a record that violates a constraint. These are the ones your code should handle, and the compiler makes you handle or declare them.

An Error signals that the JVM or the platform has hit a condition it cannot recover from: the heap is exhausted, the stack overflowed, a required class is missing at run time. Application code should not normally catch these. Catching OutOfMemoryError and trying to carry on usually fails again immediately, and swallowing it converts a clean crash into an unpredictable state. The exceptions worth catching at the top of an application are the ones that represent a request you could fail gracefully.

public class Main {
    public static void main(String[] args) {
        try {
            throw new IllegalArgumentException("a runtime exception");
        } catch (RuntimeException e) {
            System.out.println("caught runtime: " + e.getClass().getSimpleName());
        }

        try {
            throw new StackOverflowError("an error");
        } catch (Error e) {
            System.out.println("caught error   : " + e.getClass().getSimpleName());
        }

        try {
            throw new Exception("a checked exception");
        } catch (Exception e) {
            System.out.println("caught checked : " + e.getClass().getSimpleName());
        }
    }
}

The output shows that all three are catchable, because a catch clause for Throwable covers every branch. What differs is whether you should. Catching Error is occasionally done at the very top of a service to log and rethrow, but the usual pattern is to catch Exception at the boundary, log it with the stack trace, translate it into a response, and let Errors through untouched so the process dies visibly rather than limping on with a corrupted heap.

You write a catch clause naming the type, and the compiler checks that the code inside the try block can actually throw something that matches. If it can, the catch is reachable; if it cannot, the compiler reports that the exception is never thrown in the body of the corresponding try statement — which is how it tells you a catch clause is dead code.

When an exception is not caught, it propagates up the call stack. Each frame that the exception passes through gets a chance to catch it; if none does, the thread dies and the default handler prints the exception type, the message and the stack trace to the error stream. If the thread was the main thread, the JVM then exits with a non-zero status. If it was a worker thread, only that thread dies — which is a common source of silent failures in server code, since the process keeps running while the work silently stops happening.

public class Main {
    public static void main(String[] args) {
        try {
            int[] values = {1, 2, 3};
            System.out.println(values[10]);
        } catch (ArrayIndexOutOfBoundsException e) {
            System.out.println("caught: " + e.getClass().getSimpleName());
        } finally {
            System.out.println("finally always runs");
        }

        // The wrong cast is caught by its own specific type.
        try {
            Object o = "a string";
            Integer n = (Integer) o;
            System.out.println(n);
        } catch (ClassCastException e) {
            System.out.println("caught: " + e.getClass().getSimpleName());
        }
    }
}

The output shows both paths handled locally. Note that the catch clause is chosen by the compiler from the types it can prove are thrown, so the first catch binds ArrayIndexOutOfBoundsException and the second binds ClassCastException.

One design point worth raising in an interview: catching an exception at the level where you can actually do something about it is what keeps stack traces meaningful. An exception caught and rethrown immediately on every level produces a trace full of noise, while an exception handled once at the boundary keeps the frames that show where the problem really was.