In JavaScript, why is writing a `return` statement inside a `finally` block treated as a bug, and what happens to an error that was already propagating when the `finally` block itself throws?

## Pending completions, and who wins Every statement produces a completion: normal, return, throw, break or continue, each with a value. A `try` statement runs its block, records whatever completion came out, runs `finally`, and then resumes the recorded completion - *unless* the `finally` block produced an abrupt completion of its own. In that case the finally block's completion wins outright and the recorded one is discarded, unlogged and unrecoverable. That single rule explains every behaviour in this area. ## return inside finally ```js function swallow() { try { throw new Error('real failure'); } finally { return 'ok'; } } swallow(); // 'ok' - the error no longer exists ``` The throw was recorded, the finally block returned, and the return replaced it. Nothing observed the error: no handler ran, no `unhandledrejection` or top-level handler fired, no stack was printed. The function looks like it succeeded. The same override applies to an ordinary value: ```js function shadow() { try { return 'from try'; } finally { return 'from finally'; // wins } } shadow(); // 'from finally' ``` This is why linters ban it outright - ESLint's core `no-unsafe-finally` rule flags `return`, `throw`, `break` and `continue` inside a finally block. The construct is legal, occasionally used deliberately, and almost always a mistake in real code because its effect on error propagation is invisible at the call site. ## break and continue do it too Inside a loop, a `break` or `continue` in a finally block is an abrupt completion just like a return: ```js for (const id of ids) { try { load(id); // may throw } finally { if (shouldStop) break; // discards the error, exits the loop quietly } } ``` The loop ends, the error vanishes, and the log shows a clean run over fewer items than expected. This variant is harder to spot in review than the `return` one because the abrupt statement reads like ordinary loop logic. ## When the cleanup itself throws The accidental version of the same rule is far more common than the deliberate one: ```js function read(resource) { try { return resource.read(); // throws: 'connection reset' } finally { resource.close(); // also throws: 'already closed' } } ``` The caller receives `already closed`. The `connection reset` error - the one that explains what actually went wrong - is gone. Whole debugging afternoons are spent on this: the symptom that reaches the logs is a secondary failure from the cleanup path, and the cleanup path throws *because* the primary failure left things in a bad state, so the two are correlated in exactly the way that hides the cause. ## The discipline Treat `finally` as a block that must always complete normally: - never write `return`, `throw`, `break` or `continue` directly in it - turn the linter rule on and leave it on; - if a cleanup call can throw, give it its own `try/catch` inside the finally block and report the secondary failure without letting it escape; - keep cleanup narrow: release what this scope acquired, nothing more, so there is less that can fail. ```js function read(resource) { try { return resource.read(); } finally { try { resource.close(); } catch (closeError) { console.warn('close failed', closeError); } } } ``` Now the primary error propagates, and the cleanup failure is still visible in the logs rather than silently displacing it. ## Diagnosing it in an existing codebase Symptoms worth recognising: a function that reports success on inputs that clearly cannot succeed; a stack trace whose top frame is a `close`, `release` or `unlock` call and whose message describes a state problem rather than the operation you asked for; error counts in monitoring that are lower than the failure rate users report. All three point at a finally block that is deciding the outcome of the statement. Grep for `finally` blocks containing `return` first - that is a mechanical, high-yield search - then review the ones that call anything fallible. ## Where the boundary is Occasionally `return` in `finally` is used on purpose, in a wrapper that is meant to convert every outcome into a value. Even then, prefer expressing that intent explicitly with a `catch` clause that returns, so a reader can see which errors are being absorbed. The problem with the finally form is not that absorbing errors is always wrong - it is that the code gives no signal that it is happening.