What happens if __exit__ itself raises while the with body is already unwinding an exception?

`__exit__` runs while an exception is in flight, which makes it one of the few places in Python where two exceptions genuinely compete. The rule is simple and the operational consequences are not. ## The rule If `__exit__` raises, that new exception propagates out of the `with` statement and the body's exception is replaced. The return value never matters, because the method never returned. The original is preserved as implicit context: ```python try: with FlushOnExit(): # __exit__ raises RuntimeError raise ValueError("parse failed") except RuntimeError as err: err.__context__ # ValueError('parse failed') ``` Every exception object carries `__context__` (set automatically when one exception is raised during the handling of another), `__cause__` (set only by `raise ... from`), and `__suppress_context__` (set to True by `raise ... from None`). The default traceback printer walks the chain and prints the older exception first, followed by "During handling of the above exception, another exception occurred". ## Why this is a production problem, not a trivia question Consider a nightly geocoding batch: a six-hour run over address records, with a context manager that opens an output writer and flushes it in `__exit__`. One record carries a locale-dependent coordinate format - decimal commas where the parser expects points - and the body raises `ValueError`. The manager's flush then fails too, because the partially written buffer is inconsistent, and raises `OSError`. What the on-call engineer sees is an `OSError` about a write. The `ValueError` that actually caused the run to fail is three lines up in the traceback, under a sentence people skim past, and the error-routing rule that pages the data team on `ValueError` never fires. Worse, if the outer code has `except ValueError: skip_record()`, the batch no longer skips - it dies. A cleanup bug has silently changed the failure semantics of the whole job. ## Writing cleanup that does not steal the exception The discipline: **`__exit__` should not raise while unwinding unless it has something more important to say.** Concretely, guard the risky part and branch on whether an exception is already in flight: ```python def __exit__(self, exc_type, exc, tb): try: self.writer.flush() except OSError as cleanup_error: if exc_type is None: raise # nothing else was wrong; this IS the failure logging.warning("flush failed while unwinding: %s", cleanup_error) return False # body's exception keeps propagating ``` On a clean exit the flush failure is the news, so it propagates. On a failing exit the original diagnosis is more valuable, so the cleanup error goes to the log and the body's exception survives. If you want both visible to the caller and are willing to change the propagated type, be explicit: `raise CleanupError("flush failed") from exc` sets `__cause__`, which prints as "The above exception was the direct cause of the following exception" and reads as intent rather than accident. ## Two adjacent traps **Returning from a `finally` inside `__exit__`.** A `return` that leaves a `finally` block discards any exception in flight through that block - including one raised by the cleanup code you were trying to protect. Python 3.14 added a `SyntaxWarning: 'return' in a 'finally' block` (PEP 765) precisely because this silently eats errors. Put the `return` after the `try` statement instead. **Suppressing by accident during the cleanup handler.** Writing `except Exception: pass` inside `__exit__` hides teardown failures completely; if the writer never flushed, the job reports success and produces a truncated file. Log it, count it, or re-raise - never swallow silently. ## What an interviewer is listening for Three beats. First the mechanic: the cleanup exception replaces the body's exception and the original becomes `__context__`. Second the consequence: outer handlers and alert routing keyed on the original type stop matching, so the observable failure mode of the system changes. Third the remedy: branch on `exc_type is None` inside a defensive `try`/`except` in `__exit__`, and use `raise ... from` when chaining is deliberate. A candidate who only recites the first beat has read the data model; a candidate who volunteers the second has debugged a batch job at 3am.