13When it breaks

In Chapter 12 we gave data behaviour — objects that carry their own methods. Here we meet the one object nobody builds on purpose: the exception, the thing Python constructs the instant it hits a wall it can't climb. Here's the plan. We'll watch one get born on the heap, throw it, and follow it as it climbs the call stack looking for someone to catch it. Then we slip a try/except net under exactly the line that might drop, and no wider. The whole way through, we keep asking the one question that matters — when something fails, what is Python really doing in the moment before your program dies? By the end you'll read a traceback like a flight log, catch only the errors you expect while letting real bugs surface, raise errors of your own, and write an input loop that no mistyped line — 3:20 where a plain number belonged — can ever crash.

01An exception is an object, not a scream

Let's start with the thing itself. Ask Python to do something it genuinely can't — divide by zero, reach past the end of a list, look up a key that was never there — and watch what happens. It doesn't panic, and it doesn't keel over. It does something oddly calm: it builds a small object. That object lives on the heap, chapter 6's open region where every value you've ever made already sits, and its whole job is to describe what just went wrong. So read ZeroDivisionError, KeyError, ValueError not as noises the machine barks at you, but as what they really are: class names. Each one is a blueprint. A failure at runtime is a single instance of that blueprint, freshly built, with the details of the mishap tucked inside.

Then watch the object travel. Raising is Python's verb for launching it. A raised exception leaps up out of the current line, out of the current function, and up through every caller that was patiently waiting on a result — abandoning each stack frame mid-sentence as it climbs. (A stack frame is chapter 9's word for one paused function call: its local names, and the exact spot it was waiting to resume.) All the way up, it's looking for someone willing to handle it. If nobody volunteers, it runs out of frames at the very top, Python prints a traceback — the flight log of everywhere it passed through — and the program stops. That's the whole life cycle. An "error" isn't a special kind of catastrophe. It's just an ordinary object that nobody caught in time.

# our playlist entry — Blinding Lights, 200 seconds
song = {"title": "Blinding Lights", "artist": "The Weeknd", "seconds": 200}
print(song["genre"])
# KeyError: 'genre'   ← not a message barked at you —
#                      an object of class KeyError, and nobody caught it

Because it is a genuine object, you can do object things to it — even build one by hand, without anything going wrong at all. Constructing an exception and raising one are two separate acts. The object exists quietly the moment you make it, and only raise sends it flying. Here it is sitting still, letting you read its insides:

e = KeyError("genre")        # a value, constructed — not raised, nothing has failed
print(type(e).__name__)      # KeyError      — the class it is an instance of
print(e.args)               # ('genre',)    — the payload it carries
print(str(e))                # 'genre'       — its human-readable message
print(isinstance(e, LookupError))   # True — a KeyError *is a kind of* LookupError

So a runtime error is a box with a name on the lid (its class), a small parcel inside (.args), and a sentence it will read aloud if asked (str(e)). It also has an identity — id(e) is its address on the heap — and it takes up room. On this machine's CPython 3.12, sys.getsizeof(e) reports that the object itself weighs 88 bytes. A scream has no size. This has a size.

Now watch the second half of the story: the travel. Picture the call stack from chapter 9 — main() called show_song(), which reached for d["genre"]. The instant that lookup fails, a KeyError is born in the deepest frame and starts climbing. At each frame it asks the same question — is anyone here ready to catch me? Finding no one, it abandons that frame and rises to the caller. Step it through:

Traceback (most recent call last):
  File "playlist.py", line 9, in <module>
    main()
  File "playlist.py", line 7, in main
    return show_song(song)
  File "playlist.py", line 4, in show_song
    return d["genre"]
KeyError: 'genre'   ← the class, then its message. read me first.

print(issubclass(KeyError, Exception))            # True
print(issubclass(KeyboardInterrupt, Exception))  # False
print(issubclass(KeyboardInterrupt, BaseException))  # True

So an exception is a value looking for a catcher — and the whole time, we have watched no one volunteer. What does volunteering look like? Time to string a net under the risky line: try / except. →

02try / except: a net under the risky line

Some lines are safe: 2 + 2 cannot fail. Other lines are a leap over a gap — song["genre"] when there is no genre key, int("Titanium") when the text isn't a number, a file read when the disk is gone. Left alone, a leap that misses ends the program: Python raises an exception, prints a traceback, and stops. try / except is how you string a net under the risky line. try: means attempt this block, I know it might fail. except SomeError: is the net. If that kind of exception is raised anywhere inside the try block, control jumps straight into the except block — the rest of the try is abandoned, mid-flight — and the program keeps running. If nothing fails, the net is never touched, and the except block is skipped entirely.

Here is the whole idea on one small fact from our playlist. The song lives in a dict, and we reach for a field that was never stored.

song = {"title": "Blinding Lights", "artist": "The Weeknd", "seconds": 200}

try:
    dur = song["genre"]          # no 'genre' key -> raises KeyError
    print("never reached")       # skipped -- control already jumped
except KeyError as e:
    print("missing field:", e)   # missing field: 'genre'

print("still playing")           # the program survived the fall

Read the jump carefully, because it's the part that surprises people. song["genre"] raises, and print("never reached") never runs — control has already left the block. An exception is not a return value you inspect on the next line. It's a teleport out of wherever you are, in the middle of an expression. as e catches the thrown object and binds it to a name, so inside the net you can read what went wrong: here e prints as 'genre', the key that was missing. Then life resumes below the block, at still playing.

Now the sharp edge that the diagram hides: the net catches by type, and only the type you named. except KeyError is not a catch-all for "anything went wrong" — it's a net woven for KeyError and nothing else. If a different exception is raised inside the try, this net doesn't even see it. The exception sails straight past and keeps propagating, and if nothing above catches it, the program still dies. Drag the control below to fire three different lines through the same except KeyError and watch which ones the net holds — and which one falls right through it.

The net caught the fall — but two quiet questions still hang there. What should run only when nothing broke, kept out of the guarded block on purpose? And what must run no matter what — the cleanup that fires whether you sailed through, got caught, or fled the scene entirely? Python has two more blocks for exactly this, and almost everyone forgets they exist: else and finally. →

03else and finally: the two forgotten blocks

The try/except you just met is only half of a bigger machine. The full statement has four blocks, and each one answers a different question about how your risky code turned out. try: the part that might blow up. except: what to do if it does. else: the follow-on work that should run only when the risky line survived — deliberately kept out of try, so that if it fails your except can't mistake a real bug for the failure you were catching. finally: what to do no matter what — success, failure, an error nobody caught, even an early return sneaking out the side door. Most code never uses the last two, and it is quietly worse for it.

Why does the "always" block matter? Because some jobs must happen on every way out. Close the file you opened. Flush the memory-map back to disk. Hand the network buffer back. finally is the slot for that deterministic teardown. The cleanup fires the instant control leaves the block, instead of drifting until the garbage collector eventually notices (chapter 6). It's the same guarantee with automates for you (chapter 11); here you're watching the gears turn by hand.

Here are the four blocks doing real work — turning a song's printed length into minutes, and refusing to crash on a typo. It's our playlist again. The text "200" is the running time of "Blinding Lights", and int("200") is the line that might trip.

# turn a printed length into minutes — and never crash on bad text
raw = "200"                       # "Blinding Lights", read from a file
try:
    seconds = int(raw)             # the risky line — text could be "20O"
except ValueError:
    print("not a number")         # runs ONLY on failure
else:
    print(seconds // 60, "min")     # runs ONLY on success  ->  3 min
finally:
    print("done — either way")       # runs ALWAYS, on every exit path

The natural question: why bother with else — why not just drop that seconds // 60 line at the bottom of the try? Because of what try means. Code inside try is code whose failures you are volunteering to catch. If the division lived there and it somehow raised, your except ValueError net would be sitting right underneath, ready to mislabel a genuine bug as "not a number." else says something sharper: this part depends on success, but its failures are a different story — don't let my error-handler swallow them. Move the slider below and watch control re-route through the four blocks.

def length_of(raw):
    try:
        return int(raw)      # about to hand back 200...
    finally:
        return -1            # ...but this WINS — caller always gets -1

The net now catches, cleans up after itself, and stays out of the way. But a net woven wide enough to catch everything also snags the bugs you needed to watch fall through — catch the error you expect, not all of them →

04Catch the error you expect — not all of them

You wrap a risky line in try/except to survive bad input — sensible. But watch what a lazy net does. An unqualified except: (or an except Exception: reached for out of habit) catches every failure the block can raise — not just the malformed track you were bracing for, but the variable name you misspelled two lines up. Type trck when you meant track and Python raises a NameError. The same wide net scoops it up, prints your polite "bad track", and sails on. The input was perfect. Your code is broken. And nothing on the screen says so. That is the most expensive bug there is — the invisible one: a program that works and lies at the same time.

track = ("Blinding Lights", "The Weeknd", 200)

try:
    title, artist, secs = trck   # typo — you meant `track`
except:                          # bare net — swallows the NameError too
    print("bad track")           # a lie: the track was fine

# right: name the failure you expect — let bugs crash where you can see them
try:
    title, artist = track        # 3 values, 2 names: ValueError
except ValueError as e:          # the one failure you planned for
    print("malformed track:", e)

Two failures that deserve the same response? Hand except a tuple — except (ZeroDivisionError, ValueError) as e: — one block, both caught. Want different responses? Stack separate except blocks. Python reads them top to bottom and runs the first whose type matches, then stops looking. So the game is entirely about how wide you draw each net — and there's a real cost to drawing it too wide.

But being specific means knowing the names. Each built-in exception marks one exact category of impossibility. Once you can read the map, the last line of a traceback stops being noise and becomes an address that tells you precisely what to fix:

playlist = [("Blinding Lights", "The Weeknd", 200),
            ("Titanium", "David Guetta ft. Sia", 245)]
song = {"title": "Blinding Lights", "seconds": 200}

int("Titanium")          # ValueError        right type, impossible value
playlist[5]              # IndexError        position doesn't exist
song["genre"]            # KeyError          key isn't in the dict
"Blinding Lights" + 200  # TypeError         these types don't combine
200 / 0                  # ZeroDivisionError no such quotient exists
song.play()              # AttributeError    a dict has no .play
open("missing.m3u")      # FileNotFoundError the file isn't there
title, artist = playlist[0]  # ValueError    a 3-tuple into 2 names

Two of these get confused constantly. ValueError means the type was fine but the content was impossible — int("Titanium") hands int() a string exactly like int("200") does, but no integer lives inside the letters. TypeError means the operation makes no sense for these types at all — "Blinding Lights" + 200 can't even be attempted, because str and int have no shared notion of +. Type is the shape; value is what's inside the shape. One is the wrong box entirely; the other is the right box with the wrong thing in it.

You can catch the error you expect. But sometimes the impossible thing is your data, not your code — and Python won't complain until much later. Can you throw the error yourself, on purpose, the instant the rule is broken? →

05raise: signalling your own errors

Here is a value your machine will accept without a flinch: a song that lasts minus fifty seconds. Write {"Titanium": -50} and Python stores it as calmly as it stores 200. A negative integer is a perfectly ordinary integer, and Python has no opinion about what seconds mean. The impossibility isn't in the language. It's in your world, the one where a track has a real running time and a playlist is supposed to make sense. So far you've only caught failures the interpreter handed you — a bad int(), a missing key. This section flips the arrow. raise lets you throw the exception, at the exact instant nonsense tries to walk in the door, instead of letting it settle quietly into your data and detonate ten functions later when something finally divides by it.

Watch it fire. First, why invent a type at all — why not just raise ValueError("bad length")? Because a caller's except ValueError would then scoop up our complaint and every unrelated int() mishap in the same breath, unable to tell the trouble we raised from Python's. So we give ourselves a private failure type in one line — subclass Exception, done. It's a class only our code ever raises, so callers can catch exactly our trouble and swallow no one else's. Then we guard the door:

class PlaylistError(Exception):
    """Something is wrong with this playlist."""

def add_song(shelf, title, seconds):
    if seconds <= 0:
        raise ValueError(f"impossible length: {seconds}s")
    if any(t == title for t, s in shelf):   # any(): did at least one row match?
        raise PlaylistError(f"{title!r} is already on the shelf")
    shelf.append((title, seconds))

shelf = []
add_song(shelf, "Blinding Lights", 200)   # fine — lands on the shelf
add_song(shelf, "Titanium", -50)          # stops here → ValueError: impossible length: -50s

raise ValueError(...) does two things in one breath. It constructs the exception object — passing your message straight to the constructor — and it throws it, abandoning the rest of add_song mid-stride, unwinding frame by frame until some except catches it or the program dies with a traceback. The message you passed isn't stored by hand anywhere; it rides along inside the object. Catch it and str(e) hands it back, while e.args is the raw tuple you constructed it with:

try:
    add_song(shelf, "Titanium", -50)
except ValueError as e:
    print(str(e))     # impossible length: -50s
    print(e.args)     # ('impossible length: -50s',)

And because PlaylistError is your own class, a caller can write except PlaylistError and net precisely the "this playlist is broken" case — never accidentally catching a ValueError that meant something else entirely. One class line bought you a whole named category of failure. But to catch classes well, you have to see the family they belong to.

The point of raising at the door is that the door is where the truth is still local. Drag the slider below and feed add_song a length. Watch the border check either wave the value through onto the shelf, or reject it on the spot — and notice what the shelf looks like afterwards.

try:
    add_song(shelf, title, seconds)
except PlaylistError:
    log.warning("rejected a bad row")
    raise          # re-throw the same object, same traceback

def load_length(field):
    try:
        return int(field)
    except ValueError as e:
        raise PlaylistError(f"bad length field: {field!r}") from e

So which is it — inspect the value first and only then act, or just try the operation and be ready to catch it? Python has a favourite, and a proverb to match: ask forgiveness, not permission. →

06Ask forgiveness, not permission

There are two ways to touch a thing that might not be there. The first is to look before you leap — test every precondition, then act: if "genre" in song: before you ever reach for song["genre"]. Programmers call it LBYL. The second is to just try the thing and be ready to catch the fall if it fails — EAFP, "easier to ask forgiveness than permission." Python's whole culture leans hard toward the second. That isn't a fashion; it's earned, and it rests on two facts about how the world actually behaves.

First, the happy path pays almost nothing. A try block that doesn't raise is nearly free, and you touch the key once — LBYL touches it twice, once to check and again to fetch. Second, LBYL has a crack in it. Between the moment you check and the moment you act, the world is free to change. Your code confirms playlist.txt exists. A heartbeat later — before open() runs — a sync app or the user deletes it. The check passed. The action crashes anyway. EAFP has no such crack, because it never checks separately: attempting the action is the test, one motion, with no gap for reality to slip through.

The crack in LBYL isn't hypothetical — you can watch it open. Below, a file lives on disk, an LBYL program checks for it, and in the sliver of time before it acts, another process deletes it. Step through and see the check curdle into a stale yes the instant the world moves underneath it — while the EAFP program, which never asked, simply meets the missing file and catches it.

This is why the most-loved idiom in beginner Python is pure EAFP — the input loop that no bad string can crash. You don't inspect the string for stray colons and letters. You hand it to int() and let it object if it must. The one line that reads a number becomes a fortress against every malformed string. Though, exactly as section 01 promised, not against the two escape hatches that sit outside ValueError: Ctrl-C (KeyboardInterrupt) and a closed input stream (EOFError) still punch straight through and end the program, by design:

# a length-reader no bad string can crash
while True:
    try:
        secs = int(input("Length in seconds: "))
        break                 # reached only if int() did not raise
    except ValueError:
        print("Digits only — 200, not 3:20. Try again.")

print("Added a", secs // 60, "min track.")

Type 200 and you've added "Blinding Lights." Type 3:20 and int() raises ValueError, the except catches it, and the loop swings back for another try — the program never dies, and the user is simply asked again. (A tidy detail: int(" 245 ") is 245 — it forgives the spaces for you.) There was never a clean, complete "is this a valid integer?" test to write by hand. int() already is that test, and running it is how you ask.

# playlist = ["Blinding Lights", "Titanium"]
it = iter(playlist)
next(it)      # 'Blinding Lights'
next(it)      # 'Titanium'
next(it)      # StopIteration  ← the exception every for-loop catches to stop

Your playlist app now survives fat fingers, missing files, and a world that refuses to hold still — and with that, every tool in the course is on the bench. Next, the whole journey folds onto a single page: a cheat sheet of every value, structure and idiom you've earned, a glossary of the words that now mean something to you, and the road on. →