A @contextlib.contextmanager caught the with body's error and never re-raised it — what happens?

## The rule Inside a generator-based context manager the `yield` is where the body's exception arrives. What the generator does with it decides everything: * **Does not catch it** — the exception propagates out of the `with`. This is the default and almost always the right behaviour. * **Catches it and re-raises** — same outcome, but the manager got to react on the way past. * **Catches it and returns normally** — the exception is **suppressed**. The `with` statement completes, and the next line after the block runs. That third case is the generator form's equivalent of a class-based manager returning a truthy value from its exit method. There is no flag to return here; *not re-raising is the flag*. ```python import contextlib @contextlib.contextmanager def swallow(): try: yield except ValueError: pass finally: print("cleanup ran") with swallow(): raise ValueError("boom") print("execution continued") ``` Both lines print. The `ValueError` is gone: not logged, not counted, not visible to the caller. ## How it gets written by accident A nightly subscription-billing run makes the shape concrete. Someone wraps each customer's charge in a manager that opens a transaction, and adds an `except Exception:` around the yield so failures can be logged with the customer id — then rolls back, logs, and forgets the bare `raise`. Every subsequent stage behaves as though the charge succeeded: invoices are marked issued, the ledger writer runs against rows that were never committed, and the run exits zero. The defect surfaces days later as an ordering assumption that no longer holds, because a stage that depends on an earlier one now runs against partial data. The test suite does not help. A 27-minute suite whose assertions are all of the form "calling this raises nothing" is *strengthened* by a swallowing manager — the code got quieter, so the tests got greener. The assertion that would have caught it is the one nobody writes: raise a known exception inside the manager's block and assert that the same exception escapes it, with `unittest.TestCase.assertRaises` wrapped around a `with` block whose body raises. ## Related traps at the same yield **Yielding again after catching.** A generator that catches the body's exception and then hits another `yield` produces `RuntimeError: generator didn't stop after throw()`. It usually means someone tried to implement a retry by looping around the yield — a context manager cannot re-run its block, because the block is not inside the generator. Retries belong in a loop around the `with`, not inside the manager. **Replacing the exception.** If the generator raises something new while handling the body's exception, the new one propagates and the original becomes its `__context__`. That is fine when the replacement is more meaningful, but do it deliberately with `raise NewError(...) from exc`, so the chain is explicit rather than accidental. **Suppressing too broadly.** `except Exception` catches `ValueError` and also the `KeyboardInterrupt`-adjacent programming errors you wanted to see — `AttributeError`, `TypeError`, a typo'd name. If suppression is intended, name the class: `except TimeoutError:` says something; `except Exception:` says nothing. ## When suppression is legitimate Sometimes the manager exists precisely to make a class of failure non-fatal — a best-effort cache write, an optional telemetry flush, a cleanup step whose failure must not mask the real error. Two disciplines make that safe. First, keep the caught class as narrow as the intent. Second, make the suppression *visible*: log at warning level with enough identity to find the record later, or increment a counter, so "nothing raised" is not the same as "nothing happened". A manager whose whole job is to suppress one named exception is better expressed with the standard library's dedicated suppression helper than by hand-rolling an `except` around a yield, because the intent is then unmistakable at the call site. ## Reviewing for it The review question is one sentence: *does every `except` in this generator end in `raise`?* If not, the manager suppresses, and that must be intentional and documented. Combined with the `finally` rule — cleanup always, reaction only with a re-raise — it covers essentially every way a generator-based manager can lie to its caller about what happened inside the block. ## Suppression is not cleanup The last thing to keep separate is the pair of jobs a manager can do on the failure path. Cleanup — releasing what was acquired — belongs in `finally` and has no bearing on whether the caller sees the exception. Suppression — deciding the caller should not see it — happens only in an `except` that does not re-raise. Managers that blur the two end up either leaking on error or lying about success, and stating which of the two jobs a given clause is doing is usually enough to settle a review argument about it in one sentence.