Java Exception Handling: Key Patterns and Pitfalls

When a method throws an exception, the Java runtime unwinds the call stack until a matching catch block is found. That simple mechanism drives most of the decisions you make when designing error handling in Java. This article covers the practical side of java exception handling: how checked and unchecked exceptions behave, how to use try-with-resources correctly, and where common patterns go wrong.

The Two Exception Categories in Java

Java divides exceptions into checked and unchecked types. Checked exceptions are subclasses of Exception but not RuntimeException. The compiler forces you to either catch them or declare them in the method signature with throws. Unchecked exceptions extend RuntimeException and do not require explicit handling.

// Checked exception
public void readFile(String path) throws IOException {
    Files.readAllLines(Paths.get(path));
}

// Unchecked exception
public int divide(int a, int b) {
    return a / b; // ArithmeticException is unchecked
}

The distinction exists to signal intent. Checked exceptions represent conditions that a well-written application should anticipate and recover from, such as missing files or malformed input. Unchecked exceptions represent programming errors, like null dereferences or invalid arguments, where recovery is usually not possible or desirable.

How the Call Stack Determines Exception Flow

When an exception is thrown, the runtime searches backward through the call stack for the nearest enclosing try block with a matching catch. If none exists, the thread terminates and prints the stack trace. This propagation behavior means you can choose to handle an exception at the point where it occurs or let it bubble up to a higher layer.

public void process() {
    try {
        readFile("data.txt");
    } catch (IOException e) {
        log.error("Failed to read file", e);
        throw new ProcessingException("Cannot continue", e);
    }
}

Catching at the right level matters. Catching too early can leave the system in an inconsistent state if the caller needs to know about the failure. Catching too late can make the stack trace less useful because the original context is lost. A common approach is to let low-level exceptions propagate to a central handler that can log, translate, and respond consistently.

Using try-with-resources for Reliable Cleanup

Before Java 7, closing resources like streams and connections required a finally block with null checks. The try-with-resources statement simplifies this by automatically closing any AutoCloseable resource when the block exits, whether normally or due to an exception.

try (BufferedReader reader = Files.newBufferedReader(Paths.get("data.txt"))) {
    return reader.readLine();
} catch (IOException e) {
    throw new DataLoadException("Could not read input", e);
}

The resource is closed before the catch block runs, so you can rely on cleanup happening even when the read fails. This pattern also handles the case where both the body and the close operation throw; the original exception is preserved and the close exception is added as a suppressed exception, visible in the stack trace.

Creating Custom Exceptions That Carry Context

Custom exceptions let you attach domain-specific information to a failure. A well-designed custom exception includes a message, a cause, and any fields that help the caller decide how to recover.

public class OrderValidationException extends RuntimeException {
    private final String orderId;
    private final String field;

    public OrderValidationException(String orderId, String field, String message) {
        super(message);
        this.orderId = orderId;
        this.field = field;
    }

    public String getOrderId() { return orderId; }
    public String getField() { return field; }
}

Extend RuntimeException when the condition is a programming error or when you want to avoid forcing every caller to declare the exception. Extend Exception when you want the compiler to remind callers that the operation can fail. The choice affects API ergonomics, so it should be deliberate.

Common Pitfalls That Hide the Original Failure

One of the most damaging patterns is swallowing exceptions with an empty catch block. This makes the program appear to work while silently losing the root cause. Even logging the exception without rethrowing can be problematic if the caller needs to react.

// Bad: exception is lost
try {
    riskyOperation();
} catch (Exception e) {
    // do nothing
}

// Better: log and rethrow as a more specific exception
try {
    riskyOperation();
} catch (IOException e) {
    throw new ServiceUnavailableException("Backend unreachable", e);
}

Another common problem is catching Throwable or Error. Error subclasses like OutOfMemoryError are not meant to be handled; attempting to recover from them often makes the situation worse. Catching Exception is usually sufficient, and catching more specific types is even better.

Performance and Maintainability Tradeoffs

Creating an exception is expensive because the JVM captures the stack trace when the exception is instantiated. Using exceptions for normal control flow, such as terminating a loop, adds unnecessary overhead and makes the code harder to read. Reserve exceptions for exceptional conditions.

Checked exceptions have a maintainability cost. A method that declares throws Exception forces every caller to handle or propagate it, which can lead to verbose code. Some developers avoid checked exceptions by wrapping them in unchecked ones at the boundary. This tradeoff depends on the layer: low-level libraries often use checked exceptions to signal recoverable conditions, while application-level code may prefer unchecked exceptions to reduce boilerplate.

Choosing Between Checked and Unchecked Exceptions

Use a checked exception when the caller can reasonably recover by taking a different action, such as retrying with a different input or falling back to a default value. Use an unchecked exception when the failure is a programming error or when recovery is impossible without changing the caller's logic.

For example, a method that parses user-provided JSON should throw a checked ParseException because the caller might show a validation message. A method that receives a null argument should throw NullPointerException (unchecked) because the caller should have ensured the argument was non-null.

The decision also affects API evolution. Adding a checked exception to a method signature breaks all callers at compile time. Adding an unchecked exception does not, which can be useful for new failure modes in a widely used library. The right choice depends on whether the failure is an expected part of the contract or a bug.

A balanced approach is to use checked exceptions for conditions that are part of the method's documented contract and unchecked exceptions for conditions that indicate misuse. This keeps the API honest without forcing callers to handle impossible scenarios. When you do catch an exception, always preserve the original cause by passing it to the new exception's constructor, as shown in the earlier examples.