You already met the family tree of exceptions : BaseException at the very top, Exception for "normal" errors, and specific leaves like KeyError. This page does one job — it drags every distinct kind of situation into the light and works each one by hand, so you never meet a case in real code that you have not already seen here.
Intuition The one mental picture for this whole pageA raise is a ball dropped at a leaf of the tree. It rolls upward toward the root, and the first except clause it bumps into that sits on its own branch catches it. If it reaches the top (BaseException) with no match, the program crashes. Everything below is just "which branch does this ball roll up, and which handler will it hit first?"
Before any code, let us list every class of situation an exception-handling block can face. Each later example is tagged with the exact example number that fills it.
#
Case class
What is special about it
Example
A
Exact leaf match handler names the precise exception
Ex 1
B
Parent catches child handler names an ancestor, child rolls up to it
Ex 1, 2
C
Sibling divergence two children of one parent, handled together
Ex 2
D
Order matters (dead code) general-before-specific → later handler unreachable
Ex 3
E
Degenerate / zero input zero divisor, empty container, None
Ex 1, 4
F
Limiting value float result past the range ceiling → inf, not an error
Ex 4
G
BaseException trapCtrl+C / SystemExit slipping through a too-broad catch
Ex 5
H
No handler at all ball rolls off the top → crash
Ex 6
I
Real-world word problem file that may be missing or unreadable
Ex 7
J
Bare / tuple catch-all except: and except (E1, E2): idiomsEx 8
K
Exam twist else/finally + re-raiseEx 9
The rest of the page fills every one of cells A–K.
Definition Three words we will use on every ball
raise ::: the moment an error object is created and thrown upwardhandler ::: an except SomeError: clause that may catch the ballpropagate ::: the ball moving up past handlers that do not match it, toward the root
Say each aloud once — every step below is just these three verbs.
Worked example Example 1 — exact leaf, parent net, zero input (cells A, B, E)def safe_divide (a, b): try : return a / b except ZeroDivisionError : # leaf return "zero" except ArithmeticError : # parent net return "math" Call safe_divide(10, 2), then safe_divide(10, 0).
Forecast: what does each call return? Guess before reading.
safe_divide(10, 2) → no exception at all; 10/2 is 5.0, returned directly.
Why this step? No ball is dropped, so no handler runs. This is the happy path baseline every matrix needs (a case where nothing throws).safe_divide(10, 0) → 10/0 raises ZeroDivisionError. Look at figure s01: the ball starts at the ZeroDivisionError leaf and would roll up to ArithmeticError, but the first handler on that path is except ZeroDivisionError — it catches immediately.
Why this step? This is cell E (degenerate zero input) meeting cell A (exact leaf). Because the leaf handler comes first, the parent net never fires.If we deleted the ZeroDivisionError line, the ball would keep rolling and the ArithmeticError handler (cell B, parent catches child) would return "math" instead.
Why this step? Shows the net below the leaf — proving ZeroDivisionError is-a ArithmeticError.
Verify: safe_divide(10,2) == 5.0; safe_divide(10,0) == "zero". Units: dividing two pure numbers gives a pure number — consistent.
Worked example Example 2 — two siblings, one shared parent (cells B, C)def lookup (data, index, key): try : return data[index][key] # data[index] may IndexError; [key] may KeyError except LookupError as e: return f "lookup: {type (e). __name__} " Call it three ways:
lookup([{'n':'A'}], 0, 'n'), lookup([{'n':'A'}], 5, 'n'), lookup([{'n':'A'}], 0, 'age').
Forecast: which of the three throws, and what name comes out?
lookup([{'n':'A'}], 0, 'n') → data[0] is {'n':'A'}, then ['n'] is 'A'. No throw; returns 'A'.
Why this step? Baseline happy path for the lookup branch.lookup([{'n':'A'}], 5, 'n') → data[5] raises IndexError (list has 1 item). In figure s02 the IndexError ball rolls up to LookupError, matching there.
Why this step? IndexError is a child of LookupError (cell B), so the single LookupError handler catches it. Returns "lookup:IndexError".lookup([{'n':'A'}], 0, 'age') → data[0] works, but ['age'] raises KeyError, the sibling of IndexError. It rolls up the other child branch to the same LookupError. Returns "lookup:KeyError".
Why this step? This is cell C: two different leaves, one handler, because both siblings share the ancestor. type(e).__name__ still tells us which sibling threw.
Verify: returns 'A', "lookup:IndexError", "lookup:KeyError".
Worked example Example 3 — general before specific = unreachable handler (cell D)def bad_order (d, k): try : return d[k] except Exception : # general FIRST return "general" except KeyError : # DEAD — never runs return "key" bad_order({}, 'x') — what comes back?
Forecast: "general" or "key"?
d['x'] on an empty dict raises KeyError.
Why this step? Sets up the ball we will trace.
Python checks handlers top to bottom . KeyError is-a Exception, so the first handler matches. Returns "general".
Why this step? The except KeyError line below can never be reached — any KeyError was already swallowed. This is the classic dead-code bug (cell D).
The fix is to reverse them: specific KeyError first, Exception last as a net.
Why this step? Restores surgical precision — the whole reason the hierarchy exists.
Common mistake The rule this bakes inOrder handlers most-specific → most-general. A parent placed above its child makes the child's handler dead code. Python does not warn you; the tree does the picking silently.
Verify: bad_order({}, 'x') == "general".
Worked example Example 4 — integer zero-division vs float overflow-to-inf (cells E, F)
Two look-alike operations that behave very differently:
import math def kinds (a, b): try : out = a / b if isinstance (out, float ) and math.isinf(out): return "inf" # overflowed silently to infinity return out except ZeroDivisionError : return "zerodiv" Call kinds(1, 0) and kinds(1e308, 1e-10).
Forecast: does the huge-number call return a number, "inf", or crash?
kinds(1, 0) → dividing by zero raises ZeroDivisionError → "zerodiv" (cell E).
Why this step? The degenerate divisor case; there is genuinely no answer, so Python raises.
kinds(1e308, 1e-10) → the true value would be a number about 318 zeros long, far past the biggest float Python can store (roughly 1.7977e308, drawn as the red ceiling in figure s03). Key correction: ordinary float division does not raise OverflowError here — CPython quietly returns the special value float('inf') ("infinity"). So the call returns "inf", never an exception (cell F, limiting value).
Why this step? This is the trap: passing the ceiling is not an error you can except; the number silently becomes inf. You must test for inf yourself with math.isinf, which is exactly what the if line does.
Contrast: 10**1000 / 10**999 uses big integers , promotes cleanly, and simply equals 10.0 — no ceiling involved.
Why this step? Proves the ceiling is a float-range fact, not an "answer too big" fact.
Common mistake The overflow mythIt is tempting to write except OverflowError after a plain /. But float division ==overflows to inf silently==, so that handler never fires for 1e308/1e-10. Guard with math.isinf(x) instead of an except.
Verify: kinds(1,0) == "zerodiv"; 1e308/1e-10 == float('inf'); math.isinf(1e308/1e-10) is True; 10**1000/10**999 == 10.0.
Worked example Example 5 — whyexcept Exception and not except BaseException (cell G)
def guarded (fn): try : return fn() except Exception : # note: NOT BaseException return "handled" Feed it two "errors": a normal one, and a KeyboardInterrupt.
Forecast: which one gets swallowed, which one escapes?
guarded(lambda: 1/0) → ZeroDivisionError is-a Exception → caught → "handled".
Why this step? Normal errors live below Exception, so the net catches them.
Now imagine fn raises KeyboardInterrupt (the object Ctrl+C creates). In figure s04, KeyboardInterrupt hangs off BaseException beside Exception, not under it. The ball rolls up its own branch, misses except Exception, and propagates out.
Why this step? This is the whole point of the split: except Exception deliberately lets termination signals escape so Ctrl+C still stops your program.
Had we written except BaseException, we would have caught the interrupt too — the program would ignore Ctrl+C. That is cell G: the too-broad catch.
Why this step? Fixes the "catch everything" instinct with the correct boundary.
Mnemonic The line you never cross==Exception = my bugs. BaseException = the OS talking to my program (exit, Ctrl+C).== Catch the first; leave the second alone unless you are a logging framework.
Verify (structural): issubclass(ZeroDivisionError, Exception) is True; issubclass(KeyboardInterrupt, Exception) is False; issubclass(KeyboardInterrupt, BaseException) is True.
Worked example Example 6 — the ball rolls off the top (cell H)def unhandled (): try : return [][ 0 ] # IndexError except KeyError : return "key" unhandled() — return value or crash?
Forecast: does the except KeyError help at all?
[][0] on an empty list raises IndexError.
Why this step? Empty-container degenerate access — a common real bug.The only handler names KeyError. IndexError is not a KeyError and is not its child — different branch. The ball propagates past this handler.
Why this step? A handler only catches its own exception and that exception's descendants — never a sibling .
No further handler exists, so the IndexError reaches the top and crashes the function with a traceback.
Why this step? Cell H is the reminder that a try block does not magically make code safe — only matching handlers do.
Verify: calling unhandled() raises IndexError (checked by asserting the raise).
Worked example Example 7 — reading a config file that may not exist or may be locked (cell I)A program must read config.txt. Three real outcomes: it reads fine, it is missing , or it exists but the OS denies permission .
def read_config (exists, readable): try : if not exists: raise FileNotFoundError if not readable: raise PermissionError return "contents" except FileNotFoundError : return "default" # recover with a default config except PermissionError : return "denied" except OSError : return "os-safety-net" Evaluate (True,True), (False,True), (True,False).
Forecast: three inputs, three outputs — name them.
(True, True) → file present and readable → returns "contents". Happy path.
Why this step? Baseline where nothing throws.(False, True) → FileNotFoundError raised; caught by its own leaf handler → "default". We recover, not crash.
Why this step? Missing file is expected in the real world, so it deserves specific recovery — exactly what the hierarchy lets us target.(True, False) → PermissionError raised → caught by its own handler → "denied". Both FileNotFoundError and PermissionError are children of OSError, so the final except OSError stays as a safety net for the other 20+ OS errors (disk full, dropped network drive).
Why this step? Cell I combines cells A (two exact leaves) and B (parent net) in one realistic block.
Verify: returns "contents", "default", "denied" for the three inputs.
Worked example Example 8 —except: vs except (E1, E2): (cell J)
Two idioms you will meet constantly. First, the tuple form catches several specific types in one clause:
def tuple_catch (x): try : return 10 / x # ZeroDivisionError if x==0 except ( ZeroDivisionError , TypeError ): # tuple = "any of these" return "bad-input" Second, the bare form catches literally everything, like except BaseException::
def bare_catch (x): try : return 10 / x except : # bare — catches Ctrl+C too! return "swallowed" Call tuple_catch(0), tuple_catch("a"), and bare_catch(0).
Forecast: what does each return, and which idiom is dangerous?
tuple_catch(0) → 10/0 raises ZeroDivisionError, which is one of the listed types → "bad-input".
Why this step? The tuple means "match if the ball is any of these branches" — a clean way to give two sibling-ish errors the same recovery without a shared parent.
tuple_catch("a") → 10 / "a" raises TypeError (can't divide by a string), also in the tuple → "bad-input".
Why this step? Shows both members of the tuple actually fire; it is not just decoration.
bare_catch(0) → ZeroDivisionError is caught → "swallowed". But a bare except: is equivalent to except BaseException: — it would also swallow KeyboardInterrupt and SystemExit. Same danger as cell G.
Why this step? Cell J's warning: prefer the tuple form for precision; avoid the bare form for exactly the reasons Example 5 gave.
Common mistake Never leaveexcept: bare in real code
==A bare except: catches BaseException,== so it eats Ctrl+C and sys.exit(). Use except Exception: for a safe net, or a tuple except (A, B): for targeted catches.
Verify: tuple_catch(0) == "bad-input"; tuple_catch("a") == "bad-input"; bare_catch(0) == "swallowed".
Worked example Example 9 — the full try/except/else/finally flow with a re-raise (cell K)log = [] def full_flow (x): try : y = 10 / x except ZeroDivisionError : log.append( "except" ) raise ValueError ( "bad x" ) # re-raise a DIFFERENT error upward else : log.append( "else" ) # runs ONLY if no exception return y finally : log.append( "finally" ) # runs ALWAYS, last Run full_flow(2), then call full_flow(0) and catch whatever it re-raises. Then inspect log.
Forecast: in which call does "else" appear, where does "finally" land, and what error escapes full_flow(0)?
full_flow(2) → 10/2 = 5.0, no exception. The else block runs (log gets "else"), then finally runs (log gets "finally"), and the function returns 5.0.
Why this step? else is the "the try succeeded" branch — it runs only when the body threw nothing. Exams love testing that else is skipped whenever except fires.full_flow(0) → 10/0 raises ZeroDivisionError; the except runs (log gets "except") and then re-raises a new ValueError. The else is skipped (an exception occurred), but finally still runs (log gets "finally") before the ValueError leaves the function.
Why this step? This is the re-raise pattern: catch a low-level error, translate it into a meaningful one for the caller, yet finally cleanup still fires on the way out. Callers must therefore wrap full_flow(0) in their own try expecting ValueError.Catching that escaping error at the call site:
try : full_flow( 0 ) except ValueError as e: caught = str (e) # "bad x" Why this step? Confirms the re-raised type/message is what actually propagates — not the original ZeroDivisionError.
After both calls, log == ["else", "finally", "except", "finally"].
Why this step? Reading the whole log proves the ordering rule: try → (except OR else) → finally, and that finally runs even when an exception is on its way out (see context managers and 1.3.06-TryExcept-Finally for the same guarantee packaged differently).
Verify: full_flow(2) == 5.0; full_flow(0) raises ValueError with message "bad x"; final log == ["else", "finally", "except", "finally"].
Recall Quick self-testHandler order rule ::: most-specific first, most-general last, else children become dead code
except Exception catches Ctrl+C? ::: No — KeyboardInterrupt is under BaseException, beside Exception
Two siblings sharing one handler ::: name their common parent, e.g. LookupError for IndexError + KeyError
Catch several unrelated types in one clause ::: except (E1, E2): tuple form
Danger of a bare except: ::: it equals except BaseException: and swallows Ctrl+C / sys.exit()
When does else run ::: only when the try body raised nothing
When does finally run ::: always, even after a return or a re-raise inside except
Float division past the range ceiling ::: returns float('inf') silently — no exception; test with math.isinf
