Why must a @contextlib.contextmanager generator wrap its yield in try/finally?

## What actually happens at the yield A generator-based context manager suspends at its `yield` while the `with` body runs. Two things can happen next. * **The body completes normally.** The manager resumes the generator, execution continues on the line after the `yield`, and the generator is expected to finish. * **The body raises.** The manager does not resume the generator normally — it causes that exception to be raised *at the `yield` expression itself*, inside the generator frame. That second case is the whole question. From the generator's point of view, `yield` is a statement that can raise. Anything written after it is skipped for exactly the same reason that code after a `raise` is skipped, and the exception then propagates out of the generator and back out of the `with` statement. ## The failure this produces ```python import contextlib @contextlib.contextmanager def leaky(): print("acquire") yield print("release") # never runs when the body raises try: with leaky(): raise KeyError("row 27") except KeyError: print("release never printed") ``` Run it and you get `acquire`, then the KeyError, and no `release`. The manager looks correct in review, passes every test that exercises the success path, and leaks on precisely the path where cleanup matters most — the failing one. Long-running services accumulate the damage: unreturned pool connections, held locks, temp files, an unfinished span in a trace, a metric gauge never decremented. The fix is mechanical: ```python import contextlib @contextlib.contextmanager def safe(): print("acquire") try: yield finally: print("release") ``` Now the `finally` runs on both paths, and the exception still propagates because nothing caught it. ## Where setup goes relative to the try Acquire **before** the `try`, not inside it. If acquisition itself fails, there is nothing to release, and the exception should escape the factory before the block is ever entered. Putting the acquisition inside the `try` means the `finally` may run against a half-built or unbound resource and mask the original error with an `AttributeError` or `NameError`. The reliable skeleton is: ``` resource = acquire() try: yield resource finally: release(resource) ``` When there are two resources to acquire, nest the pattern or acquire the second one inside the first's `try` so each has its own `finally` — the ordering then unwinds naturally in reverse. ## Adding except without changing the contract `finally` is for cleanup that must always happen. If the manager also wants to *react* to the failure — mark a transaction rolled back, log, tag a span as errored — add an `except` around the yield, but re-raise: ```python import contextlib @contextlib.contextmanager def watched(): try: yield except ValueError as exc: print("manager saw", exc) raise finally: print("cleanup") ``` Omitting that bare `raise` changes the manager's contract from "clean up" to "swallow", which is a different and far more dangerous bug: the `with` statement then reports success. Distinguish the two deliberately — `finally` alone never alters whether the exception propagates, while `except` without `raise` always does. ## Why review misses it Three things conspire. First, the happy path exercises every line, so coverage tools show the teardown line as covered. Second, the generator form reads like ordinary sequential code, which invites the intuition that "the next line runs after the block" — true only when the block succeeded. Third, the symptom appears far from the cause: a pool exhausted an hour later, not a stack trace at the leak. The habit that prevents it is to write the `try`/`finally` skeleton first and fill in the middle, and, in review, to treat a `@contextmanager` generator with no `finally` as a defect until proven otherwise. ## A 3.14 wrinkle worth knowing Python 3.14 (PEP 765) emits a `SyntaxWarning` for a `return`, `break` or `continue` that exits a `finally` block, because such a statement silently discards an in-flight exception. Cleanup code inside the `finally` of a context manager is exactly where people used to write `return` to "stop here" — on 3.14 that construct warns at compile time, and the correct shape is to let the `finally` fall off its end so the original exception continues on its way. ## Testing it The test that catches the bug is one line longer than the one everybody writes: enter the manager, raise inside the block, assert both that the exception escaped and that the cleanup side effect happened. Any manager holding a real resource deserves that pair of assertions.