Exception Hierarchy and Builtins

## One root, two meanings Python's exception tree has a single root, `BaseException`. Anything you `raise` must be an instance of it or a class derived from it; raising anything else is itself a `TypeError`. Immediately below the root the tree forks into two categories that mean very different things. The first branch is `Exception`. This is where essentially every *error* lives: `ValueError`, `TypeError`, `KeyError`, `OSError`, `AttributeError`, `RuntimeError`, and every class you or a library derives from `Exception`. These represent "something went wrong that a caller might reasonably want to handle". The second group is three siblings of `Exception`, sitting under `BaseException` directly: * **`SystemExit`** — raised by `sys.exit()`. It is not a crash; it is a request to unwind the stack, run `finally` blocks and cleanup, and end the interpreter with a status code carried in `args`. * **`KeyboardInterrupt`** — what Python's default handler for the interrupt signal (Ctrl-C) turns the signal into. * **`GeneratorExit`** — thrown into a suspended generator when it is closed, so its `finally` blocks can run. ## Why the split exists The split is a design decision about *catchability*. Exception matching in Python is by class: `except SomeClass` matches an instance of that class or of any subclass. That single rule is what makes the hierarchy load-bearing. Because `KeyboardInterrupt` is **not** a subclass of `Exception`, a handler written to deal with errors will never intercept a user's Ctrl-C, and a long-running loop stays interruptible even though it guards every iteration. The same reasoning protects `sys.exit()`: a library that mops up errors will not silently cancel your process shutdown. ```python try: raise KeyboardInterrupt("simulated Ctrl-C") except Exception: print("never reached") except BaseException as exc: print("caught", type(exc).__name__) ``` That is also why `BaseException` is the wrong thing to name in a routine handler: naming it opts you back into catching the three signals. The legitimate uses are narrow — a rollback or cleanup block that catches broadly, does its work and immediately re-raises, or a top-level crash reporter that re-raises after logging. ## What the root class gives you `BaseException` defines the machinery every exception shares: `args` (the constructor arguments, which is what the default `str()` renders), `__traceback__`, `with_traceback`, and since 3.11 `add_note` for attaching extra lines to a traceback. Whether an exception is an error or a signal, that plumbing is identical — the difference is purely one of position in the tree. ## Groups repeat the same shape Python 3.11 added exception groups, and they mirror the split exactly. `BaseExceptionGroup` derives from `BaseException` and can hold any exceptions; `ExceptionGroup` derives from *both* `BaseExceptionGroup` and `Exception`, and its constructor rejects members that are not `Exception` instances. Construct a `BaseExceptionGroup` whose members happen to all be `Exception` instances and Python hands you an `ExceptionGroup` instead. The invariant is preserved: a group that might contain a `KeyboardInterrupt` can never be caught by a handler asking for `Exception`. ## Checking it yourself The hierarchy is introspectable, and in an interview it is worth saying you would rather check than guess: ```python for exc in (SystemExit, KeyboardInterrupt, GeneratorExit, ValueError): print(exc.__name__, issubclass(exc, Exception)) ``` `SystemExit`, `KeyboardInterrupt` and `GeneratorExit` print `False`; `ValueError` prints `True`. `__mro__` on any exception class shows the full chain up to `BaseException` and `object`. ## The practical consequences Three things follow from the split, and they are what an interviewer is really probing. First, if you want a process to remain killable with Ctrl-C, do not name `BaseException` in handlers that continue execution. Second, `sys.exit()` inside a `try` is not magic — it raises, so `finally` blocks still run and a broad enough handler can cancel it; `os._exit` is the escape hatch that skips all of that. Third, when *you* define an exception class, derive it from `Exception`, not from `BaseException`: your errors are errors, not interpreter shutdown signals, and deriving from the root would make them invisible to every reasonable handler in the codebase. ## Raising, and what counts as raisable `raise` accepts either an exception class or an instance; given a class, Python instantiates it with no arguments, so `raise ValueError` and `raise ValueError()` are equivalent. Hand it anything that is not a `BaseException` subclass or instance — a string, a plain object — and Python raises `TypeError: exceptions must derive from BaseException` instead, which is the tree enforcing its own membership rule. When you want to settle where a class actually sits rather than argue about it, `SomeError.__mro__` prints the full chain from that class up through its bases to `BaseException` and `object`.