Checked exceptions, unchecked exceptions, and try-with-resources

Every Throwable is either checked or unchecked, and the difference is entirely about the compiler, not about how serious the problem is.

public String readFile(String path) throws IOException {   // checked: must declare
    return Files.readString(Path.of(path));
}

public int divide(int a, int b) {                            // unchecked: no declaration needed
    return a / b;   // may throw ArithmeticException, uncaught
}

IOException extends Exception — checked. The compiler requires every method that can throw one to either catch it or declare it with throws, and every caller is forced to deal with that, one way or another. ArithmeticException, NullPointerException, and IllegalArgumentException all extend RuntimeException — unchecked. Nothing forces a caller to acknowledge them; they propagate silently until something up the stack catches them, or nothing does and the thread dies with a stack trace. (Error and its subclasses, such as OutOfMemoryError, are unchecked too.)

The convention: checked exceptions for conditions a well-written caller can reasonably recover from — a missing file, a failed network call. Unchecked exceptions for programmer errors — a null that should never have been null, an index that was never in range — where the fix is a code change, not a recovery path.

Try it

1public class Solution {2    public static String describe() {3        try {4            int[] nums = {1, 2, 3};5            return "value=" + nums[5];6        } catch (ArrayIndexOutOfBoundsException e) {7            return "array: " + e.getMessage();8        } catch (RuntimeException e) {9            return "runtime: " + e.getMessage();10        }11    }12}

Catch the most specific type first

try {
    process(data);
} catch (FileNotFoundException e) {   // a subclass of IOException
    // ...
} catch (IOException e) {              // the broader type
    // ...
}

A catch block matches the first clause whose type the thrown exception is an instance of, top to bottom. Putting the broader IOException first would catch everything there, and the compiler refuses to compile a narrower catch clause that can now never be reached — the ordering is enforced, not just a style preference. The hierarchy is not always obvious: NumberFormatException is a subclass of IllegalArgumentException, so a lone catch (IllegalArgumentException e) also catches every failed Integer.parseInt.

try-with-resources

try (BufferedReader reader = new BufferedReader(new FileReader(path))) {
    return reader.readLine();
}
// reader.close() has already run here, even if readLine() threw

Anything implementing AutoCloseable — a file, a database connection, a lock — declared inside the parentheses of a try is closed automatically when the block exits, success or exception, in the reverse of the order it was opened. The equivalent by hand is a finally block that has to null-check the resource (it might have failed to open) and can itself throw while closing, silently replacing the original exception. With try-with-resources the body's exception wins, and an exception from close() is attached to it as a exception () instead of hiding it.

1import java.util.*;2 3public class Solution {4    static List<String> log = new ArrayList<>();5 6    record Connection(String name, boolean closeFails) implements AutoCloseable {7        Connection {8            log.add("open " + name);9        }10        @Override public void close() {11            log.add("close " + name);12            if (closeFails) throw new IllegalStateException(name + " close failed");13        }14    }15 16    public static List<String> describe() {17        log = new ArrayList<>();18        try (Connection db = new Connection("db", false);19             Connection cache = new Connection("cache", true)) {20            log.add("working");21            throw new IllegalArgumentException("query failed");22        } catch (IllegalArgumentException e) {23            log.add("caught: " + e.getMessage());24            for (Throwable s : e.getSuppressed()) log.add("suppressed: " + s.getMessage());25        }26        return log;27    }28}

Common mistakes

• catch (Exception e) {} around a large block. It swallows the NullPointerException from your own bug along with the failure you meant to handle, and the program carries on with bad state.
• Wrapping without the cause: throw new ServiceException("load failed") loses the original stack trace. Pass it on — new ServiceException("load failed", e).
• Returning (or throwing) from finally. A return in finally replaces whatever the try block was doing, including an exception in flight, which then vanishes without a trace.

1public class Solution {2    @SuppressWarnings("finally")3    static String load() {4        try {5            throw new IllegalStateException("database is down");6        } finally {7            return "default config";   // discards the exception in flight8        }9    }10 11    public static String describe() {12        try {13            return "load() returned: " + load();14        } catch (IllegalStateException e) {15            return "caller saw: " + e.getMessage();16        }17    }18}

What interviewers ask

• Checked or unchecked — how do you decide? Checked when the caller can do something useful about it and should be made to think about it; unchecked for bugs and for failures nobody near the call site can fix. Many modern APIs lean unchecked because checked exceptions do not compose with lambdas.
• Does finally always run? For normal completion, return, break and exceptions, yes; not if the JVM halts first (System.exit, a crash) or the try never finishes.
• What happens if both the body and close() throw in try-with-resources? The body's exception propagates and the one from close() is added to it as suppressed.