How Do try, catch, and finally Interact?

The rules are precise. A try block is followed by zero or more catch blocks and then, optionally, a finally block. The catch blocks are tried in order, and the first one whose type matches the thrown exception handles it. The finally block, if there is one, runs after the try body completes normally or after a catch block handles an exception — in both cases, and also when an exception is not caught at all and is on its way out.

The order in practice: the try body runs first. If it throws, the matching catch runs. Then finally runs. If the try body completes normally, the catch blocks are skipped entirely and finally runs. If no catch matches, the exception propagates, but finally still runs first — and if finally completes normally, the original exception continues on its way.

public class Main {
    public static void main(String[] args) {
        System.out.println("result: " + compute(true));
        System.out.println("result: " + compute(false));
    }

    static int compute(boolean fail) {
        try {
            System.out.println("  try");
            if (fail) {
                throw new IllegalStateException("boom");
            }
            return 1;
        } catch (IllegalStateException e) {
            System.out.println("  catch: " + e.getMessage());
            return 2;
        } finally {
            System.out.println("  finally");
        }
    }
}

The output shows the two paths clearly. In the first call the try block throws, the catch block handles it and returns 2, and the finally block still runs before the method returns. In the second call the try block completes normally, so the catch block is skipped entirely, the finally block runs, and the method returns 1.

That last point is the one people miss: the catch block is not a mandatory step. A return inside try does not skip finally — the finally block runs first, and only then does the method return. This is why finally is the right place for cleanup that must happen on every path.

A finally block runs on every exit path from the try statement: normal completion, a caught exception, an uncaught exception on its way out, and even a return from inside the try. That guarantee is why it exists — it is the place for cleanup that must happen whatever else occurs.

Putting a return inside finally is legal Java and almost always a mistake, for two reasons. First, it discards any in-flight exception. If the try block threw and the finally block returns, the exception is swallowed and the method returns normally instead — the failure disappears without a trace. Second, it overrides a pending return from the try or catch block, so the value the caller receives is the one from finally, not the one the logic computed.

The third reason is that it breaks readability in a subtle way. A reader scanning for the return value will find the one in the try block and assume that is the answer, while the one in finally silently wins.

The safe pattern is the opposite: never return from finally. If you need to clean up and still produce a value, capture the result in a local variable inside the try block, let finally do the cleanup, and return the variable after the whole try statement. Even better, avoid the problem entirely with try-with-resources, which generates the correct closing behaviour for you and does not allow a return to defeat it.

An exception thrown inside a catch block replaces whatever was being handled — the original exception is discarded unless you attach it as the cause of the new one. An exception thrown inside a finally block does the same to any pending exception and overrides a pending return, and because finally runs last, that new exception is the one the caller sees.

The second case is the nastier one, because the original failure is lost. If a finally block throws, the stack trace you get describes the cleanup failure, and the exception that caused the cleanup to run in the first place has vanished. Attaching the original as a cause with initCause or the two-argument constructor preserves it.

public class Main {
    public static void main(String[] args) {
        try {
            try {
                throw new IllegalStateException("inner");
            } finally {
                System.out.println("finally runs before the exception propagates");
                throw new IllegalArgumentException("from finally");
            }
        } catch (IllegalArgumentException e) {
            System.out.println("caught: " + e.getMessage());
        }

        // try-with-resources closes the resource even when the body throws.
        try (java.io.BufferedReader reader = new java.io.BufferedReader(new java.io.StringReader("hello"))) {
            System.out.println("first line: " + reader.readLine());
        } catch (java.io.IOException e) {
            System.out.println("io error: " + e.getMessage());
        }
    }
}

The output shows the overriding behaviour. The inner IllegalStateException is thrown, the finally block runs, and then the finally block's own IllegalArgumentException replaces it — that is the exception the catch clause receives.

try-with-resources is the modern answer to resource cleanup because the compiler generates the closing logic and, crucially, it makes the primary exception win. If the body throws and close also throws, the body exception is the one that propagates and the close exception is attached to it as a suppressed exception, so nothing is lost. The resource is closed in reverse order of declaration, and if the body completes normally, close exceptions propagate normally.