Control Flow Inside finally

`finally` exists to guarantee that a block of cleanup runs no matter how the `try` block is left: normally, via `return`, via `break` or `continue`, or with an exception on its way out. To make that guarantee, the interpreter records *why* control is leaving — the pending outcome — runs the `finally` body, and then resumes that outcome. A `return` inside the `finally` body destroys the record. Control leaves the function immediately with the new value, and whatever was pending is discarded without a trace. ### The pending outcome is a single slot It helps to think of exactly one "reason for leaving" being carried at a time, and `finally` being allowed to overwrite it. * If the `try` block was returning `x`, that pending return is replaced. * If a `break` or `continue` was in flight, the loop jump is cancelled and the function returns instead. * If an exception was propagating, it is **swallowed**: no traceback, no logging, no `__context__` chain, nothing. The caller sees an ordinary successful return. That last case is what makes this a real production defect rather than a puzzle. A validation error, a timeout, even `KeyboardInterrupt` or `SystemExit` — all of them are dropped identically, because `finally` runs for every exit path and a `return` there ends the function unconditionally. ```python def swallow(): try: raise ValueError("gone") finally: return "clean" swallow() # 'clean' -- the ValueError never reaches the caller ``` ### The returned value is computed *before* finally runs A closely related question is what happens if the `finally` block modifies the local the `try` block returned. The answer is: nothing. `return total` first *evaluates* `total` and hands that object to the return machinery; only then does `finally` run. Rebinding the name afterwards changes the name, not the value already in flight: ```python def pick(): total = 1 try: return total finally: total = 99 pick() # 1 ``` The distinction is between *rebinding a name* (no effect on the pending return) and *executing a new `return` statement* (total override). If the returned object is mutable and `finally` mutates it in place, the caller does see the mutation — the same object is returned, in its new state. That is a mutation question, not a control-flow one. ### What Python 3.14 changed The semantics above are old and unchanged. What changed is the diagnostics. Python 3.14 implements PEP 765, which makes the compiler emit a `SyntaxWarning` whenever `return`, `break` or `continue` would transfer control *out of* a `finally` block: ``` app.py:5: SyntaxWarning: 'return' in a 'finally' block ``` Three things are worth knowing about it. First, it is a **compile-time** warning, produced when the module is compiled, not when the function runs — so it fires even for code paths never taken, and it is cached away with the `.pyc` on subsequent runs unless the source changes. Second, it is only a warning: the code still compiles and still behaves exactly as before, so 3.14 breaks nothing. Third, it can be promoted to a hard failure, which is the right move in CI: `python -W error::SyntaxWarning` or `PYTHONWARNINGS=error::SyntaxWarning` turns it into a `SyntaxError` at compile time. PEP 765 explicitly leaves the door open to making this an error in a future release, so treating it as one now costs nothing. On 3.13 and earlier the same code compiles silently; static analysers have flagged the pattern for years, which is why teams with a strict linter never hit it. The warning is scoped precisely: it fires only for statements that *leave* the `finally` block. A `return` inside a nested function defined in the `finally` body, or a `break` belonging to a loop written entirely inside the `finally` body, is not flagged, because neither one exits the block. ### How to write it instead `finally` should be for cleanup with no opinion about the outcome. Any statement that decides what the function returns belongs in `try` or in an `except` handler, where it is visible and where an exception you did not expect still escapes: ```python def pick(): try: return compute() except ValueError: return fallback() # deliberate, and typed finally: release_resources() # cleanup only, no return ``` If you genuinely want "return a default no matter what happened", say so with `except Exception:` and a `return` in the handler. That is the same outcome written honestly: the reader can see which exceptions are being absorbed, `BaseException` subclasses such as `KeyboardInterrupt` still propagate, and no future maintainer has to reason about a hidden control-flow override buried in a cleanup block.