Does a with statement catch exceptions raised in its body, or only run cleanup?

A lot of newcomers read `with` as a safer `try`/`except`. It is not. `with` is a **cleanup** construct: it promises that a paired piece of teardown code runs whether the body finishes normally, returns, breaks, or raises. Whether the *error* survives is a separate decision, and it belongs to the context manager, not to the `with` statement. ## What actually happens on the failure path A context manager is any object with `__enter__` and `__exit__`. When the body raises, the interpreter does roughly this: 1. It catches the exception internally, so it can run teardown. 2. It calls `__exit__(exc_type, exc_value, traceback)` - the class of the exception, the instance, and its traceback object. 3. It inspects the **return value** of that call. 4. If the return value is truthy, the exception is discarded and execution continues on the line after the `with` block. If it is falsy - which includes the `None` you get from a function with no `return` - the exception is re-raised and keeps propagating. So the only lever that suppresses anything is that return value. Everything else about `__exit__` is observation. ## Why the default is "propagate" A Python function that falls off the end returns `None`, and `None` is falsy. That default is deliberate: a manager author has to opt *in* to swallowing errors. Nearly every manager in the standard library declines. The file object from `open()` closes the file and returns `None`. `threading.Lock` releases and returns `None`. A database transaction manager rolls back and returns `None`. Each of them reacts to the failure and then lets it continue to whoever is in a position to decide what the failure means. ## Seeing versus catching The three arguments exist so cleanup can be *conditional*. A transaction manager commits when `exc_type is None` and rolls back otherwise; a timing manager can log "failed after 4.2s" instead of "completed in 4.2s". None of that changes whether the caller sees the error. ```python class Transaction: def __enter__(self): return self def __exit__(self, exc_type, exc, tb): if exc_type is None: self.commit() else: self.rollback() # no return -> None -> the exception keeps propagating ``` That manager reacts to every failure and hides none of them, which is what you almost always want. ## The consequences people trip over Because the exception continues, the statements *after* the `with` block do not run either - the frame unwinds normally. A junior who assumes `with open(path) as f:` will "handle" a missing file is writing code that dies at the `open()` call, before the body even starts. And a manager that closes a resource does not make the operation succeed; it only makes the resource release deterministic. ## How to actually handle the error Two placements, and they mean different things: ```python # Handle it outside: cleanup runs first, then you decide. try: with open("cities.csv") as f: rows = parse(f) except (OSError, ValueError) as err: logging.warning("batch input unusable: %s", err) # Handle it inside: the manager stays open for the rest of the body. with open("cities.csv") as f: try: rows = parse(f) except ValueError: rows = [] ``` The outside form abandons the resource as part of failing. The inside form keeps working with it. Neither one requires a custom `__exit__`. ## The one exception to the rule You *can* write a manager that suppresses - that is exactly what a truthy `__exit__` return does, and the standard library ships one whose whole job is suppression. But that is a deliberate, narrow choice, and a manager whose primary purpose is cleanup should not do it. If you find yourself unable to explain which exception types your manager swallows and why, it should be returning `None`. ## Interview framing The crisp answer is one sentence with a caveat: "`with` guarantees cleanup, not handling - the exception propagates unless the manager's `__exit__` returns a truthy value, and standard managers return `None`." That sentence separates the three ideas an interviewer is probing: that teardown is guaranteed, that `__exit__` sees the exception, and that suppression is opt-in.