What happens when a finally block contains a return (or throw)?
answer
- finally abrupt completion overrides try/catch
- return in finally replaces the try's return value
- throw/return in finally SWALLOWS the original exception
- Primitive return value is captured before finally runs
- Anti-pattern; linters flag it; use try-with-resources
basics
~20 sA return or throw in finally wins: it replaces whatever the try or catch was about to return or throw. That silently discards exceptions and is a bug, so never return or throw from finally.
solid answer
~50 sfinally completes abruptly if it executes a return, throw, break, or continue. When that happens, it overrides any pending result from the try or catch block. So if try is about to return 1 but finally does return 2, the caller sees 2. Worse, if try is throwing an exception and finally returns or throws, the original exception is silently swallowed and lost forever, destroying the stack trace and hiding the real failure. This is a well-known anti-pattern. Also note that finally can mutate but cannot change the already-evaluated return value of a primitive: 'return x;' in try captures x's value before finally runs, so mutating x in finally has no effect, while returning a mutated reference's field can leak through. The rule of thumb: finally should only do cleanup and must never use control-flow statements that complete it abruptly.
go deeper
Knows you should not put return or throw in a finally block.
Explains that finally's return overrides the try's return and can swallow an exception.
Articulates the JLS abrupt-completion override rule, the value-capture subtlety, and why try-with-resources' suppressed-exception model is the fix.
Sets codebase policy (lint rules) banning control flow in finally, and reasons about exception-fidelity and observability when designing cleanup and resource APIs.
## Background: abrupt vs normal completion Every block in Java completes either **normally** (runs off the end) or **abruptly** (via `return`, `throw`, `break`, or `continue`). The Java Language Specification defines exactly how a `try` statement combines the completion of its `try`, `catch`, and `finally` parts. The crucial rule: > If the `finally` block completes **abruptly**, that abrupt completion **replaces** any abrupt (or normal) completion produced by the `try`/`catch` block. In plain terms: whatever finally does to control flow **wins**. ## The return-override ```java int f() { try { return 1; } finally { return 2; // overrides; caller sees 2 } } ``` The `return 1` is pending, but finally's `return 2` completes abruptly and replaces it. The method returns 2. The 1 is discarded. ## The exception-swallow (the dangerous case) ```java int g() { try { throw new IllegalStateException("real bug"); } finally { return -1; // swallows the exception entirely } } ``` Here the try is completing abruptly with an exception. finally's `return -1` replaces it, so the `IllegalStateException` is **silently lost** - no stack trace, no log, the caller just gets -1 and never knows anything failed. The same happens if finally `throw`s: the new throwable replaces the original, hiding the root cause. This is why returning or throwing from finally is a documented anti-pattern (linters like Error Prone, SpotBugs, and Checkstyle flag it). ## The captured-value subtlety For a primitive or immutable return, the value is computed *before* finally runs, so mutating the variable in finally does not change what was returned: ```java int h() { int x = 1; try { return x; // value 1 is captured here } finally { x = 99; // too late; does NOT affect the returned 1 } } // returns 1 ``` But you *can* still override by explicitly returning in finally, and you *can* observe mutations through a returned reference's fields (the reference is captured, but the object it points to is shared and mutable). ## Why it is an anti-pattern - It silently destroys exceptions, the worst kind of failure: errors that vanish. - It makes control flow non-local and hard to read. - It defeats the purpose of finally, which is cleanup, not producing results. ## The correct pattern Keep finally to side-effect-free-of-control-flow cleanup. If close() itself can throw, either let try-with-resources handle it (it attaches the close failure as a *suppressed* exception rather than replacing the primary one) or catch and log within finally without returning/throwing out of it.
- How does try-with-resources avoid the exception-swallowing problem?If both the body and close() throw, try-with-resources keeps the body's exception as primary and attaches close()'s as a suppressed exception (Throwable.getSuppressed), so nothing is lost.
- Does mutating a returned primitive variable inside finally change the result?No. The return value is captured when the return statement executes in try, before finally runs, so the later mutation is ignored.
saying these in an interview costs you the question
- Thinking the try's return wins over finally's return (finally wins)
- Not realizing a return in finally silently eats a pending exception
- Believing mutating a primitive in finally changes the captured return value
- Using finally to compute and return a result instead of just cleaning up