If a context manager's __enter__ raises, is its __exit__ still called?

The `with` statement's promise is narrower than it first appears. It is not "this manager will always be cleaned up"; it is "**a manager that successfully entered will always be exited**". The gap between those two sentences is where resource leaks live. ## The mechanic Executing a `with` statement does three things in order: evaluate the manager expression, look up `__enter__` and `__exit__` on its type, and call `__enter__`. Only after `__enter__` returns does the interpreter arm the cleanup that will call `__exit__`. So if `__enter__` raises: - the exception propagates out of the `with` statement itself, - the body never executes, - the `as` target is never bound, - and `__exit__` is never called for that manager. There is no partial-cleanup magic. The interpreter has no idea what `__enter__` acquired before it failed. ## Why that leaks, and whose job it is A realistic manager acquires more than one thing: ```python class GeocodeBatch: def __enter__(self): self.conn = connect(self.dsn) # step 1 succeeds self.output = open(self.path, "w") # step 2 raises OSError return self ``` If step 2 raises, the connection from step 1 is now unreferenced and unclosed, and `__exit__` will never run to close it. Over a six-hour nightly run that retries the batch every few minutes, that is a steady drip of connections until the pool is exhausted - and the traceback points at the file open, not at the leak. Ownership is unambiguous: **`__enter__` must be exception-safe on its own.** Acquisition is either all-or-nothing, or it cleans up what it took: ```python def __enter__(self): self.conn = connect(self.dsn) try: self.output = open(self.path, "w") except BaseException: self.conn.close() raise return self ``` Catch `BaseException` rather than `Exception` here, because a `KeyboardInterrupt` arriving mid-acquisition leaks exactly the same way. Re-raise bare so the original exception and traceback are preserved. ## Ordering with several managers The per-manager rule answers the ordering question directly. `with A() as a, B() as b:` is equivalent to nesting: `A` is entered, then `B`. If `B.__enter__` raises: 1. `A.__exit__(exc_type, exc, tb)` is called, with `B`'s exception, because `A` did enter successfully. 2. `B.__exit__` is not called, because `B` never entered. 3. Whatever `A.__exit__` returns decides whether `B`'s acquisition error propagates - a truthy return from `A.__exit__` would swallow it, which is one more reason unconditional suppression is dangerous. Managers always unwind in reverse order of entry, so cleanup mirrors acquisition. The same holds for `try`/`finally` written by hand, and for any dynamic-cleanup helper: each resource is only registered for release once its acquisition succeeded. ## The mirror case: failing before `__enter__` There is a second gap that is easy to miss. If the expression that *constructs* the manager raises - `open("/missing/path")` inside `with open("/missing/path") as f:` - there is no manager object at all, so neither `__enter__` nor `__exit__` runs. This is why `with open(...)` does not protect you from a missing file: that error happens before the statement has anything to manage. ## How to answer Lead with the rule and the reason: `__exit__` is armed only after `__enter__` returns, so a manager that fails mid-acquisition must unwind itself. Then volunteer the multi-manager ordering, because that is what distinguishes someone who has memorised the sentence from someone who has reasoned about it: already-entered managers *do* get their `__exit__`, in reverse order, and they receive the exception that came out of the failing `__enter__`. ## Spotting it in review Three cheap checks catch nearly every instance. First, does `__enter__` contain more than one acquiring call - a connect, an `open`, an `acquire`, a `mkdtemp`? If so it needs its own guard. Second, does the class store acquired handles on `self` before it can fail again, with `__exit__` as the only place they are released? That is the leak signature. Third, is the manager acquiring several unrelated resources at once? Composing one manager per resource, entered in sequence, hands the ordering problem back to the language: each nested manager that entered gets its `__exit__`, in reverse order, with no hand-written unwinding to get wrong. The version that leaks is almost always the version somebody wrote to save a level of nesting.