What Sits Under the Exception Hierarchy?

Every exception in Python descends from BaseException, and almost everything you will catch descends from Exception.

print(issubclass(ValueError, Exception))          # True
print(issubclass(KeyError, LookupError))          # True
print(issubclass(LookupError, Exception))         # True
print(issubclass(KeyboardInterrupt, Exception))    # False

# Catching the base class catches the subclass
try:
    raise KeyError("missing")
except LookupError as err:
    print("LookupError caught:", type(err).__name__)

The LookupError clause catches a KeyError, because KeyError inherits from LookupError. That is the whole mechanism: an except clause names a class, and it catches that class and everything below it in the tree.

Useful subtrees to know. Under Exception sit ArithmeticError, which covers ZeroDivisionError, OverflowError and FloatingPointError; LookupError, which covers KeyError, IndexError and AttributeError; and OSError, which covers FileNotFoundError, PermissionError, TimeoutError and the rest of the file and network errors. Catching LookupError is often the right level when you want to handle any kind of lookup failure without caring which one it was.

The last line is the one to notice. KeyboardInterrupt is not a subclass of Exception, so an except Exception clause will not catch it — it derives directly from BaseException, along with SystemExit and GeneratorExit. Those three are control-flow signals rather than errors.

The hierarchy has two roots that matter. BaseException is the top, and directly below it sit Exception and three control-flow signals: KeyboardInterrupt, SystemExit and GeneratorExit. Everything else inherits from Exception, and Exception is the boundary between ordinary errors and the signals used to stop a program.

Below Exception the tree fans out into useful families. ArithmeticError covers ZeroDivisionError, OverflowError, FloatingPointError and the decimal errors. LookupError covers KeyError, IndexError and AttributeError — the three ways a lookup can go wrong. OSError covers the file and networking errors, with FileNotFoundError, PermissionError, IsADirectoryError, TimeoutError and ConnectionError under it. And there are the specific ones such as TypeError, ValueError, StopIteration and ZeroDivisionError that sit directly under Exception.

The advice on what to catch depends on where you are. In application code, catch the narrowest type you can actually handle — a ValueError from parsing input, an OSError from a file. In library code, define your own exceptions derived from Exception, and document them. At the top level of a program, catch Exception, log it with the traceback, and shut down cleanly. Never catch KeyboardInterrupt or SystemExit unless you genuinely mean to.

One design note that earns credit: because the hierarchy is a tree, catching a middle node like LookupError lets you handle several related failures with one clause while still letting callers catch the specific one.

Catching Exception covers every ordinary error, but the three control-flow signals derive from BaseException directly and slip past it.

try:
    raise KeyboardInterrupt()
except Exception:
    print("never printed")
except BaseException:
    print("caught by BaseException")


try:
    raise SystemExit(0)
except Exception:
    print("never printed either")
except BaseException as err:
    print("SystemExit is a BaseException:", type(err).__name__)

The first block prints only the second line. The KeyboardInterrupt is not a subclass of Exception, so the first clause does not match and the BaseException clause catches it instead. The second block shows the same thing for SystemExit.

This is exactly why a bare except is a bad idea. A bare except catches BaseException, so it would swallow the interrupt a user sends with Ctrl-C and the clean exit a program requests. A program that swallows KeyboardInterrupt cannot be stopped, and it will look like it is hanging.

There is one legitimate reason to catch BaseException, and it is narrow: at the very top of a program, in a handler that must guarantee cleanup — logging the error, flushing a buffer, shutting down a service — and then re-raising the exception so the exit status is still correct. The re-raise is the essential part.