Why does a Python traceback sometimes print two exceptions joined by "During handling of the above exception"?

### What the interpreter is doing Every exception instance carries three chaining attributes: `__context__`, `__cause__` and `__suppress_context__`. Implicit chaining is about the first of them. When CPython raises an exception, it checks whether another exception is currently *being handled* — that is, whether the frame stack has an active handler that has not yet finished. If there is one, the interpreter sets `new.__context__ = old` before the new exception starts propagating. No syntax requests this and no library performs it; it is part of raising. "Being handled" is broader than "inside an `except` block", which is where people first meet it. The context is also set when a `finally` block raises while an exception is unwinding, when a context manager's `__exit__` raises while cleaning up after a failure, and when a generator raises during close. Each of those is a place where a second failure would otherwise erase the first, so the language keeps the first. ### How the default display decides what to print The traceback renderer walks the chain before printing. Its rule, in order: 1. If `exc.__cause__` is not `None`, print that exception first, then the line "The above exception was the direct cause of the following exception:". 2. Otherwise, if `exc.__suppress_context__` is `False` and `exc.__context__` is not `None`, print the context first, then the line "During handling of the above exception, another exception occurred:". 3. Otherwise print nothing but this exception. So the sentence you see is a report about which attribute was populated. "During handling" means an implicit link with no `from` clause anywhere. "Direct cause" means someone wrote `raise ... from exc`. Because the chain prints oldest-first, the exception at the **bottom** of the output is the one that terminated the program and the one whose type an outer `except` would have to match. Reading it backwards — treating the top block as the fatal error — is the single most common misreading of a chained traceback. ### Reading the two blocks as a diagnosis An implicit chain usually says one of two things. **A handler is buggy.** The code caught something and then broke while reacting: a `KeyError` on a missing key, then an `AttributeError` on `None` inside the handler that tried to build the error message. The bottom exception is the one to fix; the top one is the situation the code was already in. **A wrap was intentional but sloppy.** The code caught a low-level error and raised a domain-level one without `from`, so Python attached the original as context anyway. The traceback still shows everything, but it says "during handling" — which reads to a stranger like an accident — when the author meant "this is the cause". Writing `raise DomainError(...) from exc` changes the wording to "direct cause" and states the intent. ### Working with it in code The attributes are ordinary attributes, so a handler can inspect them: ```python try: try: {}["sample_id"] except KeyError: raise RuntimeError("row is unusable") except RuntimeError as exc: print(type(exc.__context__).__name__) # KeyError print(exc.__cause__) # None print(exc.__suppress_context__) # False ``` That last triple is the fingerprint of implicit chaining, and it is what a log processor checks when it wants to walk to the deepest failure rather than report the wrapper. ### The costs to know about A chained exception keeps the older exception alive, and each exception keeps its `__traceback__`, which keeps frames, which keep the locals of those frames. A deep chain held in a module-level variable can therefore hold a surprising amount of memory. Inside a handler this is bounded — CPython clears the `as` name at the end of the `except` block for exactly this reason — but storing exceptions on long-lived objects re-introduces it. CPython also avoids building a context loop: when it sets `__context__` it will not link an exception into a chain that already contains it, so the renderer terminates. Code that assigns `__cause__` by hand has no such protection and should still be written defensively. ### Version notes Implicit chaining and the exact wording of both sentences arrived with Python 3.0 (PEP 3134) and are unchanged through 3.14. Nothing in the 3.10–3.14 line altered when `__context__` is set or how the default traceback renders it.