How does contextlib.suppress(FileNotFoundError) differ from try/except/pass?

### What `suppress` is `contextlib.suppress(*exceptions)` stores the exception classes you pass and implements `__exit__` roughly as "if an exception is in flight and it is an instance of one of my classes, return `True`; otherwise return `False`". In the `with` protocol, a true return from `__exit__` means the manager has handled the exception, so the interpreter discards it and execution continues after the block. That single rule is the entire mechanism, and it makes the equivalence exact: ```python with contextlib.suppress(FileNotFoundError): os.remove(path) # is the same as try: os.remove(path) except FileNotFoundError: pass ``` So the honest answer to "how do they differ" starts with: at runtime, they do not. What differs is what the code communicates and how it fails as it is edited. ### Why the `with` form is preferred **It names an intention, not an omission.** `except X: pass` is indistinguishable from a handler someone forgot to finish; `suppress(X)` says the swallowing is the point. Linters and reviewers treat the two very differently for that reason. **It resists the drift that creates real bugs.** A `try` block accumulates statements over time, and every statement added inside it silently comes under the same blanket `pass`. A `suppress` block invites the same drift, but the one-line form makes an over-broad body obvious in review — and the discipline is the same either way: put the *single* operation you are willing to lose inside, and nothing else. **It composes.** Because it is an ordinary object, a `suppress` instance can be created once and reused, and it is reentrant — nesting the same instance inside itself is safe, since it carries no per-use state. Most context managers cannot claim that. ### The trap: the rest of the block does not run This is what interviewers actually probe. Because the exception unwinds to the `with` statement, every remaining statement in the body is skipped: ```python with contextlib.suppress(OSError): os.remove(tmp) # raises FileNotFoundError log("cleaned up") # never runs print("here") # runs ``` Candidates who picture `suppress` as "ignore the error and carry on with the next line" get this wrong. It is not a per-statement `on error resume next`; it is a jump to the end of the block. That is why a two-statement body is almost always a mistake, and why the safe habit is one operation per `suppress`. ### Matching rules - Matching uses the normal `except` rule: an exception matches if it is an instance of one of the given classes **or of a subclass**. `suppress(OSError)` therefore swallows `FileNotFoundError`, `PermissionError`, `IsADirectoryError` and the rest of the `OSError` family — much broader than people expect. - Multiple classes are passed as separate arguments: `suppress(FileNotFoundError, PermissionError)`, mirroring the tuple after `except`. - You pass **classes**, not instances. `suppress(ValueError("x"))` is a bug; you get a `TypeError` about catching classes that do not inherit from `BaseException`. - `suppress()` with no arguments suppresses nothing, which is occasionally useful as a computed no-op. - It cannot catch what is not raised inside the block — an exception from the expression that builds the manager, or from code after the block, is untouched. ### Exception groups (3.12 and later, so true on 3.14) Since Python 3.12, `suppress` understands `ExceptionGroup`. If the block raises a group, the matching exceptions are split out and suppressed and the remainder is re-raised as a group; if every member matches, nothing is raised at all. Before 3.12 a group simply did not match the listed classes and propagated whole. This matters wherever code runs concurrent work that aggregates failures. ### Where it is the wrong tool `suppress` is for a condition you genuinely expect and genuinely do not care about: deleting a file that may already be gone, closing something that may already be closed, killing a process that may have exited. It is not a way to make a flaky call stop reporting. Two smells worth naming out loud: `suppress(Exception)` around a block of real work, which hides bugs indiscriminately, and a `suppress` whose body has grown to several statements. When you need to *know* that the thing failed, you need a real handler, not suppression — the decision of whether to swallow or report is a separate design question from the mechanics here. ### What to say in an interview "It is `try`/`except X: pass` with the intent stated in one line. `__exit__` returns `True` for matching classes, subclasses included, and because the exception unwinds to the `with`, the rest of the body is skipped — so I keep exactly one operation inside. On 3.12 and later it also splits matching exceptions out of an `ExceptionGroup`."