Checked vs Unchecked Exceptions in Java

The dividing line is whether the exception extends RuntimeException. If it does, it is unchecked; if it extends Exception but not RuntimeException, it is checked.

The compiler treats them differently. When a method may throw a checked exception, every call site must either catch it or declare it in its own throws clause. The compiler enforces this, and the effect is that you cannot call a method that can fail without explicitly deciding what to do about the failure. Unchecked exceptions need no such declaration — they propagate automatically, and the compiler lets you ignore them.

The rationale for the split is about who can act on the failure. A checked exception represents a condition outside the program's control that a caller can plausibly recover from: a file that might not exist, a network that might time out, a row that might violate a constraint. Requiring the caller to decide forces that decision to be made. An unchecked exception represents a programming error — a null reference, a bad argument, an index out of range — where the only sensible response is to fix the code, so forcing a catch clause on every caller would be noise that hides the bug rather than surfacing it.

The practical consequence people trip over is that unchecked exceptions can propagate out of any method without being declared, so a method's throws clause tells you nothing about every failure it might produce. Only the checked ones are part of its published contract. That is why libraries tend to throw unchecked exceptions for programming errors and checked ones for recoverable I/O conditions, and why the throws clause of a well-designed API is short and meaningful.

Throw a checked exception when the failure is a condition the caller can reasonably be expected to handle, and the method is part of a contract that says so. Reading a configuration file that may not exist is the canonical example: the caller can supply a default, ask the user, or fail the request cleanly. A method that reads a file should declare throws IOException, and every caller is then forced to make a decision at the call site.

Throw an unchecked exception when the failure means the caller made a mistake. Passing a negative quantity to a method that requires a positive one, or a null where null is forbidden, is not something the caller can handle gracefully at run time — it is a defect that should be fixed. Declaring those in a throws clause would clutter every call site without adding information.

The practical decision rule: if the caller has a sensible recovery action, make it checked; if the only sensible action is to fail fast, make it unchecked.

import java.io.IOException;

public class Main {
    public static void main(String[] args) {
        // The compiler refuses this call unless IOException is handled or declared.
        try {
            loadConfig();
        } catch (IOException e) {
            System.out.println("checked   : " + e.getClass().getSimpleName());
        }

        // Unchecked: the compiler lets this through without a declaration.
        try {
            int value = Integer.parseInt("not a number");
            System.out.println(value);
        } catch (NumberFormatException e) {
            System.out.println("unchecked : " + e.getClass().getSimpleName());
        }
    }

    // A checked exception: the caller must handle it or declare it.
    static void loadConfig() throws IOException {
        throw new IOException("config file missing");
    }
}

The output shows the two behaviours side by side. The loadConfig call would not compile without the catch or a throws clause, because IOException is checked. The parseInt call compiles without any declaration at the call site, and the NumberFormatException it raises is caught locally.

One more piece of the design puzzle: when you catch a checked exception and cannot handle it, declare it rather than swallowing it. Propagating it upward keeps the failure visible and lets the layer that can actually act on it decide what to do. The one thing you should never do is catch a checked exception and rethrow it as an unchecked one without attaching the original as the cause, because that destroys the information your caller needs.