Does a `break` inside a Python `try` block still run the `finally` clause?

The guarantee is simple to state and worth stating precisely: **`finally` runs on every path out of its `try` statement.** That includes falling off the end of the suite, an exception propagating, and each of the three jump statements — `break`, `continue` and `return`. Cleanup written in `finally` therefore happens before the loop is abandoned, not after and not never. ### Ordering The `finally` body runs *first*, then the pending jump resumes. A `break` inside a `try` is best read as "stage a break, run the cleanup, then take it". You can see the interleaving directly: a loop that breaks on its second pass still prints from `finally` for that pass before the statement after the loop runs. When `try` statements nest, control unwinds innermost outwards, running each `finally` it passes through. A `break` in a doubly nested `try` inside a loop runs both cleanups, inner first, before the loop ends. The same applies when the jump crosses `with` blocks: each synchronous context manager's `__exit__` runs, in reverse order of entry, with `None` for all three exception arguments because no exception is in flight. That is the mechanism behind the everyday claim that an early `break` cannot leak an open file or a held lock — the guarantee belongs to the statement, not to the loop. ### The clause that does *not* run The `try` statement's own `else` suite is the exception. It runs only when the `try` body completes without raising *and* without jumping — so a `break` skips it while still running `finally`. This trips people up because both clauses feel like "the happy path". They are not: `else` means "the body finished", `finally` means "control is leaving". Note that this is the `else` belonging to `try`, which is a different clause from the one a `for` or `while` loop can carry. ### Why it is designed this way Without the guarantee, `finally` would be useless: any early exit would be a way to skip cleanup, and every resource release would need to be repeated before every `break` and `return`. Attaching the cleanup to the statement rather than to the exit route is what lets you write the release exactly once. The compiler implements this by routing each exit through the `finally` code before the jump completes, which is why the cost is paid even on the ordinary fall-through path. ### Where it bites in practice A `finally` that runs per pass runs on the `break` pass too, so anything counted there — a metric increment, a log line, a release of a per-row resource — fires for the row that triggered the exit as well. When a reconciliation loop over a 6,800-row batch breaks on the first row whose recomputed amount drifts from the reported one, the `finally` bookkeeping for that row has already run; a total that looks off by exactly one row is usually this, not a real accounting bug. The other practical consequence is timing. A `finally` performing slow cleanup delays the `break` for as long as it takes, and a `finally` that blocks forever means the loop never exits at all. Cleanup on the early-exit path is still on the critical path. ### The dangerous inverse Everything above concerns a jump inside the `try` (or `except`) suite. Putting the jump inside `finally` itself is a different construct with a nasty semantics: control leaving a `finally` block by `break`, `continue` or `return` discards whatever was in flight — including an exception that was propagating — so the error simply vanishes. Python 3.14 (PEP 765) emits a `SyntaxWarning` for exactly that shape. `continue` inside `finally` was in fact a `SyntaxError` before Python 3.8. ### Answering well Say "yes, and it runs before the break takes effect", then add the two refinements that show real understanding: `return` and `continue` behave identically, and the `try` statement's `else` clause is skipped where `finally` is not. If you have room, note that `with` gives the same guarantee through `__exit__`, and that the reverse arrangement — a `break` inside `finally` — is the one to avoid.