Overbroad except Clauses

## Two roots, not one Every raisable object in Python inherits from `BaseException`. Directly beneath it sit five classes on 3.14: `Exception`, `KeyboardInterrupt`, `SystemExit`, `GeneratorExit` and `BaseExceptionGroup`. That split is deliberate design, not an accident of history. `Exception` is the root of *program errors* -- things your code did wrong or the world did to it: a bad value, a missing key, a closed socket. The other four are *control signals*: the interpreter or the user telling the program to stop or unwind, expressed through the same raise/propagate machinery because that machinery already knows how to run every `finally` block on the way out. You can check the shape yourself: ```pycon >>> [c.__name__ for c in BaseException.__subclasses__()] ['BaseExceptionGroup', 'Exception', 'GeneratorExit', 'KeyboardInterrupt', 'SystemExit'] >>> issubclass(KeyboardInterrupt, Exception) False ``` ## What the two clauses compile to `except Exception:` catches `Exception` and everything under it. A bare `except:` has no type at all and catches whatever propagates -- it behaves exactly like `except BaseException:`. The two spellings are interchangeable in effect; the bare form is merely shorter and, for that reason, far more common in code written in a hurry. ## Why the difference bites Three concrete consequences follow, and interviewers ask about the first one. **Ctrl-C stops working.** When you press Ctrl-C, the interpreter raises `KeyboardInterrupt` in the main thread. If a loop body is wrapped in a bare `except:` that logs and continues, the interrupt is caught like any other error and the loop keeps going. The operator presses Ctrl-C harder, sees a log line each time, and eventually reaches for a kill signal. **An exit request is swallowed.** `sys.exit()` works by raising `SystemExit`. Called inside a bare-except block, it is caught and discarded, and execution simply carries on past the point where the author believed the program had stopped. **Generator teardown is corrupted.** When a suspended generator is closed, `GeneratorExit` is thrown in at the suspension point. Code that catches it and refuses to finish turns a clean shutdown into a `RuntimeError`. A fourth case matters for async code: `asyncio.CancelledError` has inherited from `BaseException` since 3.8, exactly so that a blanket `except Exception:` cannot eat a cancellation. That is only a protection if you do not then write a bare `except:` around the awaited call. ## The rule of thumb The narrower the type, the better the handler. Prefer the specific class you can actually recover from: ```python try: rate = rates[currency] except KeyError: rate = fetch_rate(currency) ``` Widen to `except Exception:` only where a boundary genuinely needs one: the body of a worker loop that must not die because one item is bad, a request handler, a plugin call. Even there, keep the guarded block small, and record the failure with `logging.exception` so the traceback survives. Never write a bare `except:` where you meant `except Exception:`. There is no case where the extra breadth is what you wanted by accident. ## When catching BaseException is correct There is a legitimate pattern, and it always ends in a re-raise: ```python try: do_work() except BaseException: flush_partial_results() raise ``` Here you are not *handling* the interrupt, you are running cleanup on the way past it. The bare `raise` re-raises the exception being handled, so Ctrl-C still terminates the program and the exit request still exits. If your handler does not end in `raise`, catching `BaseException` is a bug. `contextlib.suppress` is the safe way to say "ignore this specific failure": ```python from contextlib import suppress with suppress(FileNotFoundError): remove_stale_cache_file() ``` It names the types explicitly, so it cannot accidentally swallow an interrupt. ## Version notes The `BaseException`/`Exception` split is stable across all of Python 3. Two additions are worth knowing: `asyncio.CancelledError` moved to `BaseException` in 3.8, and 3.11 (PEP 654) added `BaseExceptionGroup` as a direct child of `BaseException`, with `ExceptionGroup` under `Exception`. So a group carrying only ordinary errors is catchable by `except Exception:`, while a group that may carry a `KeyboardInterrupt` deliberately is not. ## Spotting it Every mainstream Python linter flags the bare form -- the rule is usually named for "bare except" or "blind except" -- and turning it into a CI error is a two-minute fix that removes the whole class of bug from a codebase.