Checked versus unchecked and the philosophy behind them

Understanding Checked versus unchecked and the philosophy behind them

Everything you can throw in Java descends from Throwable, which splits into Error, Exception, and inside Exception the subtree rooted at RuntimeException. Checked exceptions are defined by exclusion: any Throwable that is neither a RuntimeException nor an Error. For those, and only those, javac applies the handle-or-declare rule at every call site, so the call either sits inside a try with a matching catch or the enclosing method repeats the type in its own throws clause. Nothing else about the two families differs: the bytecode for a throw is identical, and the JVM unwinding the stack has no idea which category it is carrying.

The split encodes a guess about who can do something useful. A checked exception claims the failure comes from the world rather than from the code, such as a deleted file, a dead socket or an interrupted thread, which a correct caller cannot prevent but can often route around by retrying or falling back, so forgetting to consider it was made a compile error. Unchecked exceptions cover the opposite case, a null reference, an index past the end, an argument that was never legal, where no runtime handler repairs the situation and the real fix is editing the program, so demanding a catch at every call would only add noise. Error is a third case reserved for the JVM itself being in trouble, where the honest response is usually to let the thread die instead of catching.

The mechanism has a well known cost, which is why this is a design decision and not a formality. A checked exception is part of your public signature, so it climbs through every intermediate layer, each of which must handle it or advertise it, and advertising IOException from a repository interface leaks the fact that today's implementation happens to touch a disk. Checked types also do not fit functional interfaces such as Function or Supplier, whose methods declare no throws, which is why much modern library code leans unchecked and translates SQLException-style failures into a runtime hierarchy at the boundary. The practical question is not whether a failure is serious, but whether the caller has a decision to make and whether the failure belongs to the abstraction you are publishing.

The distinction is enforced per call site by the compiler, which is also why it disappears the moment a value crosses into reflective or generic code the compiler cannot inspect.

import java.io.IOException;

public class CheckedVsUnchecked {

    // The whole rule: a throwable is checked unless it is a RuntimeException
    // or an Error. There is no keyword for it, only the class hierarchy.
    static boolean isChecked(Class<? extends Throwable> type) {
        return !RuntimeException.class.isAssignableFrom(type)
            && !Error.class.isAssignableFrom(type);
    }

    // The caller cannot prevent this, but it can fall back to a default.
    static String loadSetting(String key) throws IOException {
        throw new IOException("no config source for " + key);
    }

    // A broken precondition: only fixing the caller helps.
    static int elementAt(int[] data, int index) {
        return data[index];
    }

    public static void main(String[] args) {
        Class<?>[] types = {
            IOException.class,
            InterruptedException.class,
            IllegalArgumentException.class,
            ArrayIndexOutOfBoundsException.class,
            StackOverflowError.class
        };
        for (Class<?> type : types) {
            System.out.println(type.getSimpleName() + " -> checked="
                + isChecked(type.asSubclass(Throwable.class)));
        }

        try {
            loadSetting("port");
        } catch (IOException e) {
            System.out.println("compiler forced this catch: " + e.getMessage());
        }

        System.out.println("elementAt -> " + elementAt(new int[] {7, 8}, 1));
    }
}

Worked examples

import java.io.IOException;

public class OverrideContract {

    static class Loader {
        String load() throws IOException {
            return "from disk";
        }
    }

    static class MemoryLoader extends Loader {
        @Override
        String load() {
            throw new IllegalStateException("cache not warmed");
        }
    }

    public static void main(String[] args) {
        Loader loader = new MemoryLoader();
        try {
            System.out.println(loader.load());
        } catch (IOException e) {
            System.out.println("io failure: " + e.getMessage());
        } catch (IllegalStateException e) {
            System.out.println("escaped the declared contract: " + e.getMessage());
        }
    }
}

import java.util.List;
import java.util.function.Function;

public class LambdaFriction {
    public static void main(String[] args) {
        Function<String, Integer> toInt = Integer::parseInt;
        for (String raw : List.of("10", "x")) {
            try {
                System.out.println(raw + " -> " + toInt.apply(raw));
            } catch (NumberFormatException e) {
                System.out.println(raw + " -> rejected by " + e.getClass().getSimpleName());
            }
        }
    }
}

Important notes

Common mistakes

Try it yourself