Exception Handling

What is an Exception?

An exception is an event that disrupts the normal flow of a program. When something goes wrong at runtime, such as dividing by zero, trying to open a file that does not exist, or calling a method on a null reference, the JVM creates an exception object that describes the problem and hands it off to the exception handling mechanism.

Without exception handling, an unhandled exception terminates the program and prints a stack trace to the console. With it, you can intercept the problem, respond to it gracefully, clean up any resources you were using, and decide whether to continue or to re-signal the problem to the caller with more context.

Exception Hierarchy

Every exception in Java is an object. The root of the entire hierarchy is java.lang.Throwable. Only objects that are instances of Throwable can be thrown with the throw keyword or caught with a catch block. Throwable has two direct subclasses: Error and Exception.

Checked vs Unchecked Exceptions

Java divides exceptions into two groups based on how the compiler treats them. This distinction is one of the most important things to understand early, because it determines what the compiler will and will not enforce on you.

try and catch Block

The try block contains the code that might throw an exception. The catch block follows it and is only executed if the try block throws an exception of the declared type. If no exception is thrown, the catch block is skipped entirely and execution continues normally after the try-catch structure.

The exception object caught by the catch block is a normal Java object. You can call getMessage() to get a description of what went wrong, getClass().getSimpleName() to get the exception type name, and printStackTrace() to print the full call stack to standard error.

Multiple catch Blocks and Catch Order

A single try block can be followed by multiple catch blocks, each handling a different exception type. The JVM tries them in the order they are written and executes the first one that matches the thrown exception.

The ordering rule is strict: more specific exception types must come before more general ones. If you place a catch for Exception before a catch for NullPointerException, the compiler produces an error because the NullPointerException handler would be unreachable: every NullPointerException is also an Exception, so it would already be caught by the parent handler.

finally Block

The finally block runs after the try and catch blocks have finished, regardless of what happened. Whether the try block completed normally, threw an exception that was caught, or threw an exception that was not caught, the finally block still runs. This makes it the right place for cleanup code: closing files, releasing database connections, freeing locks, or logging completion.

The only situations where a finally block does not execute are a JVM crash, a call to System.exit(), or the thread being killed forcibly. In all normal circumstances, finally is guaranteed to run.

try-with-resources (Java 7+)

Before Java 7, closing resources reliably required a try-finally block that was often long and error-prone. If the try body and the finally block both threw exceptions, the one from the finally block would silently swallow the original exception. Java 7 introduced try-with-resources to solve this cleanly.

Any class that implements the AutoCloseable interface (which includes Closeable) can be declared in the try parentheses. The JVM guarantees that close() is called on each resource when the block exits, in the reverse order of declaration. If both the try body and the close() method throw exceptions, the close exception is added as a suppressed exception and the original try-body exception propagates, which is the correct behaviour.

throw Statement

The throw statement lets your code deliberately raise an exception. You pass it an instance of any class that extends Throwable. In practice, you almost always throw an Exception subclass, not an Error. Once a throw statement executes, the normal flow stops immediately and the JVM begins looking for a suitable catch block, travelling up the call stack.

Throwing an exception is the right way to signal that a method received invalid input or that a precondition was not met. It is far better than returning a sentinel value (like -1 or null) because the caller cannot accidentally ignore an exception the way it can ignore a return value.

throws Keyword

The throws keyword appears in a method signature and declares that the method may throw one or more checked exceptions. It is a contract with the caller: "I might not complete normally, and here is the type of problem I might signal." The caller must then either catch those exceptions or propagate them further by adding its own throws clause.

You can technically use throws with unchecked exceptions too, but it is not required by the compiler and adds noise without enforcement. It is occasionally done as documentation when the unchecked exception is a meaningful part of the method's contract.

Common Built-in Exceptions

Java ships with a rich set of exception types. The ones below are the ones you will encounter most often in everyday Java code. Recognising them on sight makes debugging significantly faster.

Multi-catch Block (Java 7+)

Before Java 7, if you wanted to handle two unrelated exception types with the same code, you had two options: write duplicate catch blocks or catch their nearest common ancestor (usually the too-broad Exception). Java 7 introduced the multi-catch block to eliminate this awkwardness.

Separate the exception types with a pipe character (|) inside one catch clause. The caught variable is implicitly final in a multi-catch block, which means you cannot reassign it inside the handler. You also cannot list exception types that are in a parent-child relationship in the same multi-catch, because the child would be redundant.

Custom Exception Classes

The built-in exceptions cover a lot of ground, but there are times when none of them accurately describes a domain-specific problem in your application. Creating a custom exception class gives you a named type that callers can catch precisely, and it lets you carry additional context beyond a plain string message.

The convention is straightforward: extend Exception if the condition is something callers should be required to handle (a checked exception), or extend RuntimeException if it represents a programming error or a condition the caller cannot reasonably recover from (an unchecked exception). Always provide at least two constructors: one that takes a message string, and one that takes a message string plus a cause (the wrapped original exception).

Exception Chaining (initCause and getCause)

Exception chaining is the practice of catching a low-level exception and wrapping it inside a higher-level exception before re-throwing. This preserves the original cause rather than losing it, while also allowing you to present a more meaningful error type to the caller.

The most common way to chain exceptions is to pass the original exception as the second argument to the new exception's constructor. All standard exception constructors accept a Throwable cause parameter. To retrieve the wrapped cause later, call getCause() on the caught exception. initCause() is an alternative when you cannot pass the cause to the constructor directly, though this situation is rare with modern exception classes.

Quiz - Test Your Knowledge

Ten questions covering the exception hierarchy, checked and unchecked exceptions, try-catch-finally, try-with-resources, throw and throws, common built-in exceptions, custom exceptions, exception chaining, and multi-catch blocks. Read each option carefully before selecting your answer.