Why does `except Exception` not catch SystemExit from sys.exit()?

## The placement, and why it was chosen Python's built-in exceptions all descend from `BaseException`, but they split immediately into two families. Almost everything a program should handle — `ValueError`, `OSError`, `KeyError` — lives under `Exception`. A small set of control-flow signals hang off `BaseException` directly instead, and `SystemExit` is one of them, alongside `KeyboardInterrupt` and `GeneratorExit`. ```pycon >>> SystemExit.__mro__ (<class 'SystemExit'>, <class 'BaseException'>, <class 'object'>) ``` The split exists so that the idiomatic broad handler works. `except Exception` is the way to say "catch any error this operation might raise, log it, keep serving". If `SystemExit` were an `Exception`, every such handler in every library on the stack would also intercept a deliberate shutdown, and a process asked to exit would keep running for reasons its author never wrote down. Making the exit signal a sibling of `Exception` rather than a child of it means the two intentions — "handle errors" and "let shutdown through" — are expressed by the same line of code. ## What that looks like in practice Consider a receiver that processes queued webhook deliveries and wraps each one so a bad payload cannot take the service down: ```python import sys def handle(payload): if payload == "shutdown": sys.exit(0) raise ValueError("bad payload") for payload in ("junk", "shutdown"): try: handle(payload) except Exception as exc: print("logged and continuing:", exc) ``` The `ValueError` is caught and the loop continues; the `sys.exit(0)` is not caught, propagates out of the loop, and ends the process with status 0. That is the designed behaviour, and it is why `except Exception` is the correct broad handler. ## The bare except trap Change that handler to a bare `except:` and the behaviour inverts. A bare `except:` clause is defined as catching `BaseException`, so it catches `SystemExit` as well: ```python import sys for attempt in range(2): try: sys.exit(1) except: print("swallowed the exit on attempt", attempt) print("process still alive") ``` This script prints both attempts and then exits 0. Everything the author intended — abort now, tell the supervisor status 1 — was discarded. In a long-running service the symptom is worse than a wrong status: the process becomes hard to stop, because each exit attempt is absorbed and the loop takes another lap. The same trap appears in less obvious spellings: `except BaseException:` written by someone who wanted "catch everything"; `contextlib.suppress(BaseException)`; and a plugin or task dispatcher that catches broadly so one misbehaving handler cannot kill the worker. In every case the fix is the same — handle `Exception`, and if you must handle `BaseException` for logging, re-raise afterwards: ```python try: do_work() except BaseException: log_crash() raise ``` ## Cleanup still happens A common misconception is that `SystemExit` skips cleanup because it is "special". It does not. It is an ordinary exception object travelling an ordinary unwinding path: `finally` blocks run, `with` statements call `__exit__`, and a generator being closed sees its cleanup. The only thing special about `SystemExit` is what happens if nobody catches it — instead of printing a traceback and exiting 1 like any other uncaught exception, the interpreter exits quietly with the status carried on the exception's `code` attribute. ## Catching it on purpose Sometimes you *want* to intercept the exit. The usual case is testing an entry point: you want to assert that a bad argument produces status 2 without your test runner's process dying. Catch it by name and read `code`: ```python import sys import unittest def main(argv): if len(argv) < 2: sys.exit(2) return 0 class CliTest(unittest.TestCase): def test_missing_argument_exits_2(self): with self.assertRaises(SystemExit) as caught: main(["tool"]) self.assertEqual(caught.exception.code, 2) ``` Note that `code` is whatever was passed — an `int`, `None`, or a string message — not a normalized status. A test asserting `code == 1` against a `sys.exit("message")` call will fail even though the process would have exited 1. ## The rule to state in an interview Use `except Exception` for error handling; it is broad enough for real errors and narrow enough to let shutdown through. Never write a bare `except:` — it is a `BaseException` handler wearing a disguise. Catch `SystemExit` only where intercepting an exit is the actual intent, and re-raise anything you caught only to observe.