13When it breaks

In Chapter 12 we gave data behaviour: objects that carry their own methods. In this one we meet the one object nobody builds on purpose: the exception. Python constructs it 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 hunting 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 thing that actually 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. You'll 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 can ever crash — not even 3:20 where a plain number belonged.

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. Watch what it does. 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. 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, up through every caller that was patiently waiting on a result. As it climbs it is abandoning each stack frame mid-sentence. (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.) It hunts 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. You can 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 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; 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.

total = 0
try:
    for s in ["200", "3:20", "245"]:   # Blinding Lights, a slip, Titanium
        total += int(s)
except ValueError:
    print("skipped a bad one")
print("total:", total)

skipped a bad one
total: 200

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

# Type 1 - the bare minimum: one net, one named type
try:
    print(song["genre"])
except KeyError:
    print("no genre stored")

# Type 2 - `as e` binds the thrown object so you can read it
try:
    print(song["genre"])
except KeyError as e:
    print("missing key:", e, "| class:", type(e).__name__, "| args:", e.args)

# Type 3 - one net, two types: hand except a tuple
for raw in ("200", "3:20"):
    try:
        print(raw, "->", int(raw) // 60, "min")
    except (ValueError, TypeError) as e:
        print(raw, "-> rejected:", e)

# Type 4 - two nets, two responses. Order is law: specific first.
def length_of(box, key):
    try:
        return int(box[key]) // 60
    except KeyError:
        return "no such field"
    except ValueError:
        return "field is not a number"

print(length_of(song, "genre"))
print(length_of({"seconds": "3:20"}, "seconds"))
print(length_of(song, "seconds"), "min")

# what the bare net would swallow, and Exception would not
print("Ctrl-C is an Exception? ", issubclass(KeyboardInterrupt, Exception))
print("Ctrl-C is a BaseException?", issubclass(KeyboardInterrupt, BaseException))

you see
no genre stored
missing key: 'genre' | class: KeyError | args: ('genre',)
200 -> 3 min
3:20 -> rejected: invalid literal for int() with base 10: '3:20'
no such field
field is not a number
3 min
Ctrl-C is an Exception?  False
Ctrl-C is a BaseException? True

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. 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. It is 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 most code 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 — cleanup that 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.

you type
def parse(raw):
    print("  try     :", repr(raw))
    try:
        n = int(raw)
    except ValueError:
        print("  except  : not a number")
        return -1
    else:
        print("  else    : parsed", n)
        return n
    finally:
        print("  finally : always - even on the way out through return")

print("returned", parse("200"))
print("returned", parse("20O"))

# finally also fires while an exception is still climbing
def strict(raw):
    try:
        return int(raw)
    finally:
        print("  finally : fired with the ValueError still in flight")

try:
    strict("20O")
except ValueError as e:
    print("caught upstairs:", e)

# else runs OUTSIDE the net, so its own failures are not caught here
def demo():
    try:
        seconds = int("200")
    except ValueError:
        print("  except  : never runs")
    else:
        print("  else    : parsed", seconds, "- now dividing by zero")
        return seconds / 0
    finally:
        print("  finally : still runs")

try:
    demo()
except ZeroDivisionError as e:
    print("the else block's error sailed past the except beside it:", e)

you see
  try     : '200'
  else    : parsed 200
  finally : always - even on the way out through return
returned 200
  try     : '20O'
  except  : not a number
  finally : always - even on the way out through return
returned -1
  finally : fired with the ValueError still in flight
caught upstairs: invalid literal for int() with base 10: '20O'
  else    : parsed 200 - now dividing by zero
  finally : still runs
the else block's error sailed past the except beside it: division by zero

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 flow 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 →

you type
from pathlib import Path

Path("night.m3u").write_text("Blinding Lights\nTitanium\n", encoding="utf-8")

# Type 1 - the shape: open it, use it, and it is closed for you
with open("night.m3u", encoding="utf-8") as f:
    first = f.readline().strip()
print("first line :", first)
print("f.closed   :", f.closed)

# Type 2 - it still closes when the block blows up mid-read
try:
    with open("night.m3u", encoding="utf-8") as f2:
        raise ValueError("something went wrong mid-read")
except ValueError as e:
    print("caught     :", e)
print("f2.closed  :", f2.closed)

# Type 3 - the same promise, written by hand
f3 = open("night.m3u", encoding="utf-8")
try:
    print("by hand    :", f3.readline().strip())
finally:
    f3.close()
print("f3.closed  :", f3.closed)

# the name survives the block; only the file is shut
try:
    f.read()
except ValueError as e:
    print("reuse      :", e)

# the trap `with` exists to remove: cleanup for a file that never opened
try:
    f4 = open("missing.m3u", encoding="utf-8")
    try:
        print(f4.read())
    finally:
        f4.close()
except FileNotFoundError as e:
    print("honest     :", type(e).__name__, "- the real error, not a NameError")

Path("night.m3u").unlink()

you see
first line : Blinding Lights
f.closed   : True
caught     : something went wrong mid-read
f2.closed  : True
by hand    : Blinding Lights
f3.closed  : True
reuse      : I/O operation on closed file.
honest     : FileNotFoundError - the real error, not a NameError

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, like 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. It 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.

Traceback (most recent call last):
  File "tally.py", line 11, in <module>
    print(minutes("200"))
          ^^^^^^^^^^^^^^
  File "tally.py", line 5, in minutes
    print("dropped so far:", skipped)
                             ^^^^^^^
UnboundLocalError: cannot access local variable 'skipped' where it is not associated with a value

  File "parse.py", line 3
    except ValueError, e:
           ^^^^^^^^^^^^^
SyntaxError: multiple exception types must be parenthesized

bad length
Traceback (most recent call last):
  File "minutes.py", line 8, in <module>
    print(minutes(None))
          ^^^^^^^^^^^^^
  File "minutes.py", line 3, in minutes
    return int(raw) // 60
           ^^^^^^^^
TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

# read_the_traceback.py -- one crash, three frames deep. Read it from the bottom up.

def to_seconds(raw):                    # frame 3 - the crash site
    # int("4:05") has no integer inside it
    return int(raw)

def make_track(title, raw):             # frame 2
    return {"title": title, "seconds": to_seconds(raw)}

def load_playlist(rows):                # frame 1
    tracks = []
    for title, raw in rows:
        tracks.append(make_track(title, raw))
    return tracks

rows = [("Blinding Lights", "200"), ("Titanium", "4:05")]   # row 2 is the bad one

# 1 - catch it, and read the flight recorder yourself, link by link
try:
    load_playlist(rows)
except ValueError as e:
    print("class   :", type(e).__name__)
    print("message :", e)
    frames = []
    tb = e.__traceback__                # a linked list, oldest frame first
    while tb is not None:
        frames.append(tb)
        tb = tb.tb_next
    for tb in frames:
        print(f"  frame : {tb.tb_frame.f_code.co_name:<14} line {tb.tb_lineno}")
    print("  locals at the crash site:", dict(frames[-1].tb_frame.f_locals))

# 2 - now let it fly uncaught, and read what Python prints
load_playlist(rows)
print("never reached")

class   : ValueError
message : invalid literal for int() with base 10: '4:05'
  frame : <module>       line 20
  frame : load_playlist  line 13
  frame : make_track     line 8
  frame : to_seconds     line 5
  locals at the crash site: {'raw': '4:05'}
Traceback (most recent call last):
  File "read_the_traceback.py", line 34, in <module>
    load_playlist(rows)
  File "read_the_traceback.py", line 13, in load_playlist
    tracks.append(make_track(title, raw))
                  ^^^^^^^^^^^^^^^^^^^^^^
  File "read_the_traceback.py", line 8, in make_track
    return {"title": title, "seconds": to_seconds(raw)}
                                       ^^^^^^^^^^^^^^^
  File "read_the_traceback.py", line 5, in to_seconds
    return int(raw)
           ^^^^^^^^
ValueError: invalid literal for int() with base 10: '4:05'

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? →

# fix_the_net.py -- one bare except, two failures it should never have touched
shelf = {"blinding lights": 200, "titanium": 245}


# ---------- the program as found ----------
def lookup_broken(name):
    try:
        return f"{shlf[name]} seconds"     # typo: shlf, not shelf -> NameError
    except:                                # bare net: swallows the typo AND Ctrl-C
        return "not on the shelf"

print("broken :", lookup_broken("titanium"), " <- a lie, the song IS on the shelf")


# ---------- the repair: name the one failure you expect ----------
def lookup(name):
    try:
        return f"{shlf[name]} seconds"     # same typo, still there
    except KeyError:                       # the only failure we planned for
        return "not on the shelf"

try:
    lookup("titanium")
except NameError as e:
    print("fixed  : NameError surfaced ->", e)


# ---------- with the typo repaired, the net does exactly its job ----------
def lookup_fixed(name):
    try:
        return f"{shelf[name]} seconds"
    except KeyError:
        return "not on the shelf"

print("fixed  :", lookup_fixed("titanium"))
print("fixed  :", lookup_fixed("levels"))


# ---------- and Ctrl-C is no longer eaten ----------
def play(name):
    try:
        if name == "^C":
            raise KeyboardInterrupt        # stands in for you pressing Ctrl-C
        return f"playing {name}"
    except KeyError:
        return "not on the shelf"

try:
    play("^C")
except KeyboardInterrupt:
    print("fixed  : Ctrl-C flew straight through - the program is quittable again")

print("proof  : issubclass(KeyboardInterrupt, Exception) ->",
      issubclass(KeyboardInterrupt, Exception))

# ------------- what it prints -------------
broken : not on the shelf  <- a lie, the song IS on the shelf
fixed  : NameError surfaced -> name 'shlf' is not defined
fixed  : 245 seconds
fixed  : not on the shelf
fixed  : Ctrl-C flew straight through - the program is quittable again
proof  : issubclass(KeyboardInterrupt, Exception) -> False

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.

you type
class PlaylistError(Exception):
    """Anything wrong with a playlist."""

def add(shelf, title, seconds):
    if not isinstance(seconds, int):
        raise TypeError(f"seconds must be int, got {type(seconds).__name__}")
    if seconds <= 0:
        raise ValueError(f"impossible length: {seconds}s")
    shelf.append((title, seconds))

# Type 1 - build and throw in one breath
shelf = []
add(shelf, "Blinding Lights", 200)
for title, secs in [("Titanium", -50), ("Levels", "3:23")]:
    try:
        add(shelf, title, secs)
    except (ValueError, TypeError) as e:
        print(f"{type(e).__name__}: {e}")
print("shelf :", shelf)

# Type 2 - bare raise: note it, then let the SAME object keep flying
def add_logged(shelf, title, seconds):
    try:
        add(shelf, title, seconds)
    except ValueError:
        print("log   : rejected", title)
        raise

try:
    add_logged(shelf, "Titanium", -50)
except ValueError as e:
    print("caller still sees:", e)

# Type 3 - raise ... from e: translate the failure, keep the cause on record
def load_length(field):
    try:
        return int(field)
    except ValueError as e:
        raise PlaylistError(f"bad length field: {field!r}") from e

try:
    load_length("4:05")
except PlaylistError as e:
    print("domain error :", e)
    print("caused by    :", repr(e.__cause__))

# raise a class, not an instance - Python builds it for you
try:
    raise PlaylistError
except PlaylistError as e:
    print("bare class   :", repr(e), "| args:", e.args)

# and the one thing you may not throw
try:
    raise "the playlist is broken"
except TypeError as e:
    print("not throwable:", e)

you see
ValueError: impossible length: -50s
TypeError: seconds must be int, got str
shelf : [('Blinding Lights', 200)]
log   : rejected Titanium
caller still sees: impossible length: -50s
domain error : bad length field: '4:05'
caused by    : ValueError("invalid literal for int() with base 10: '4:05'")
bare class   : PlaylistError() | args: ()
not throwable: exceptions must derive from BaseException

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. It never accidentally catches 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.

you type
# Type 1 - one line, and you own a whole named category of failure
class PlaylistError(Exception):
    """Base for every failure this module raises."""

# Type 2 - children, so a caller picks how wide a net to cast
class SongNotFoundError(PlaylistError):
    """No song by that title on the shelf."""

# Type 3 - a child carrying fields of its own (chapter 12's __init__ and super())
class PlaylistFullError(PlaylistError):
    def __init__(self, name, limit):
        super().__init__(f"{name!r} is full at {limit} songs")
        self.name = name
        self.limit = limit

shelf = {"Blinding Lights": 200, "Titanium": 245}

def find(title):
    if title not in shelf:
        raise SongNotFoundError(f"{title!r} is not on the shelf")
    return shelf[title]

def add(title):
    if len(shelf) >= 2:
        raise PlaylistFullError("Night drive", 2)
    shelf[title] = 0

# it inherits everything an exception needs, for free
e = SongNotFoundError("Levels")
print("class  :", type(e).__name__)
print("args   :", e.args, "| str(e):", str(e))
print("is a PlaylistError?", isinstance(e, PlaylistError), "| an Exception?", isinstance(e, Exception))
print("tree   :", " -> ".join(c.__name__ for c in type(e).__mro__))

# a caller catches YOURS narrowly, or the whole family in one clause
for job in (lambda: find("Levels"), lambda: add("Levels")):
    try:
        job()
    except SongNotFoundError as err:
        print("narrow :", err)
    except PlaylistError as err:
        print("family :", type(err).__name__, "-", err)

# the extra fields ride along inside the object
try:
    add("Faded")
except PlaylistFullError as err:
    print("fields :", err.name, "|", err.limit)

# and it never catches a ValueError that meant something else
try:
    int("4:05")
except PlaylistError:
    print("never printed")
except ValueError as err:
    print("not ours:", err)

you see
class  : SongNotFoundError
args   : ('Levels',) | str(e): Levels
is a PlaylistError? True | an Exception? True
tree   : SongNotFoundError -> PlaylistError -> Exception -> BaseException -> object
narrow : 'Levels' is not on the shelf
family : PlaylistFullError - 'Night drive' is full at 2 songs
fields : Night drive | 2
not ours: invalid literal for int() with base 10: '4:05'

# jukebox_errors.py -- three failures, one family
class JukeboxError(Exception):
    """Base: anything this jukebox refuses to do."""

class CoinRejectedError(JukeboxError):
    """The money is wrong."""
    def __init__(self, paid, price):
        super().__init__(f"paid {paid}c, the price is {price}c")
        self.paid, self.price = paid, price

class SelectionError(JukeboxError):
    """The code punched in maps to no song."""
    def __init__(self, code):
        super().__init__(f"no song at code {code!r}")
        self.code = code

class QueueFullError(JukeboxError):
    """No room left in tonight's queue."""
    def __init__(self, limit):
        super().__init__(f"queue is full at {limit} songs")
        self.limit = limit


CATALOGUE = {"A1": "Blinding Lights", "A2": "Titanium", "B1": "Levels"}
PRICE, LIMIT = 50, 2
queue = []

def select(code, paid):
    if paid < PRICE:
        raise CoinRejectedError(paid, PRICE)
    if code not in CATALOGUE:
        raise SelectionError(code)
    if len(queue) >= LIMIT:
        raise QueueFullError(LIMIT)
    queue.append(CATALOGUE[code])
    return CATALOGUE[code]


for code, paid in [("A1", 50), ("Z9", 50), ("A2", 20), ("B1", 50), ("B1", 50)]:
    try:
        song = select(code, paid)
    except CoinRejectedError as e:
        print(f"refund     {e}")
    except SelectionError as e:
        print(f"try again  {e}")
    except JukeboxError as e:            # the family net holds the rest
        print(f"sorry      {type(e).__name__}: {e}")
    else:
        print(f"queued     {song}")

print("queue      :", queue)
print("tree       :", " -> ".join(c.__name__ for c in QueueFullError.__mro__[:4]))
print("one net    :", [c.__name__ for c in (CoinRejectedError, SelectionError, QueueFullError)
                       if issubclass(c, JukeboxError)])

# ------------- what it prints -------------
queued     Blinding Lights
try again  no song at code 'Z9'
refund     paid 20c, the price is 50c
queued     Levels
sorry      QueueFullError: queue is full at 2 songs
queue      : ['Blinding Lights', 'Levels']
tree       : QueueFullError -> JukeboxError -> Exception -> BaseException
one net    : ['CoinRejectedError', 'SelectionError', 'QueueFullError']

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. Then 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. →

# guard.py -- one door, and nothing malformed gets past it
REQUIRED = ("title", "artist", "seconds")

def check_track(row):
    """Return the row unchanged if it is a usable track. Otherwise raise, loudly."""
    if not isinstance(row, dict):
        raise TypeError(f"track must be a dict, got {type(row).__name__}")
    missing = [field for field in REQUIRED if field not in row]
    if missing:
        raise KeyError(f"track is missing {', '.join(missing)}")
    if not isinstance(row["title"], str) or not row["title"].strip():
        raise ValueError(f"title must be a non-empty string, got {row['title']!r}")
    if isinstance(row["seconds"], bool) or not isinstance(row["seconds"], int):
        raise TypeError(f"seconds must be int, got {type(row['seconds']).__name__}")
    if not 1 <= row["seconds"] <= 3600:
        raise ValueError(f"seconds out of range 1-3600: {row['seconds']}")
    return row

rows = [
    {"title": "Blinding Lights", "artist": "The Weeknd", "seconds": 200},
    {"title": "Titanium", "artist": "David Guetta"},
    {"title": "   ", "artist": "Avicii", "seconds": 203},
    {"title": "Levels", "artist": "Avicii", "seconds": "3:23"},
    {"title": "One Dance", "artist": "Drake", "seconds": True},
    {"title": "Faded", "artist": "Alan Walker", "seconds": -212},
    ["Uptown Funk", "Mark Ronson", 270],
]

shelf = []
for row in rows:
    try:
        shelf.append(check_track(row))
    except (TypeError, ValueError, KeyError) as e:
        print(f"reject  {type(e).__name__:<10} {e}")
    else:
        print(f"accept  {row['title']}")

print("shelf   :", [t["title"] for t in shelf])

# ------------- what it prints -------------
accept  Blinding Lights
reject  KeyError   'track is missing seconds'
reject  ValueError title must be a non-empty string, got '   '
reject  TypeError  seconds must be int, got str
reject  TypeError  seconds must be int, got bool
reject  ValueError seconds out of range 1-3600: -212
reject  TypeError  track must be a dict, got list
shelf   : ['Blinding Lights']

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. Write 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.

you type
song = {"title": "Blinding Lights", "seconds": 200}

# Type 1 - LBYL: look before you leap. Ask first, then act.
if "genre" in song:
    genre = song["genre"]
else:
    genre = "unknown"
print("LBYL :", genre)

# Type 2 - EAFP: do it, and handle the truth you actually meet.
try:
    genre = song["genre"]
except KeyError:
    genre = "unknown"
print("EAFP :", genre)

# Type 3 - the built-in shortcut, for this one case
print(".get :", song.get("genre", "unknown"))

# on a conversion, the hand-written check is quietly wrong
for raw in ("245", "-50", "  245 "):
    lbyl = int(raw) if raw.isdigit() else None
    try:
        eafp = int(raw)
    except ValueError:
        eafp = None
    print(f"{raw!r:>9}  isdigit->{raw.isdigit()!s:<5} LBYL={lbyl!s:<5} EAFP={eafp}")

# and the price, measured here: 1,000,000 lookups each
import timeit
setup = 'song = {"title": "Blinding Lights", "seconds": 200}'
N = 1_000_000
hit_lbyl = timeit.timeit('song["title"] if "title" in song else None', setup=setup, number=N)
hit_eafp = timeit.timeit('try:\n song["title"]\nexcept KeyError:\n pass', setup=setup, number=N)
miss_lbyl = timeit.timeit('song["genre"] if "genre" in song else None', setup=setup, number=N)
miss_eafp = timeit.timeit('try:\n song["genre"]\nexcept KeyError:\n pass', setup=setup, number=N)
print(f"key present : LBYL {hit_lbyl:.3f}s   EAFP {hit_eafp:.3f}s")
print(f"key absent  : LBYL {miss_lbyl:.3f}s   EAFP {miss_eafp:.3f}s")

you see
LBYL : unknown
EAFP : unknown
.get : unknown
    '245'  isdigit->True  LBYL=245   EAFP=245
    '-50'  isdigit->False LBYL=None  EAFP=-50
 '  245 '  isdigit->False LBYL=None  EAFP=245
key present : LBYL 0.027s   EAFP 0.017s
key absent  : LBYL 0.020s   EAFP 0.114s

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. Meanwhile 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.

# robust_input.py -- one function that refuses to hand back nonsense

def get_int(prompt, low=None, high=None):
    """Ask until the answer is a whole number inside [low, high]. Never raises on bad text."""
    while True:
        raw = input(prompt)
        try:
            value = int(raw)
        except ValueError:
            print(f"  {raw!r} is not a whole number. Digits only - 200, not 3:20.")
            continue
        if low is not None and value < low:
            print(f"  {value} is below the minimum of {low}.")
            continue
        if high is not None and value > high:
            print(f"  {value} is above the maximum of {high}.")
            continue
        return value


def get_int_or(prompt, default, low=None, high=None):
    """Same, but a closed input stream falls back instead of crashing."""
    try:
        return get_int(prompt, low, high)
    except EOFError:
        print(f"  (input closed - falling back to {default})")
        return default


# --- a staged keyboard, so this run is reproducible on your machine too ---
typed = iter(["3:20", "-90", "9000", "200"])

def input(prompt=""):                  # shadows the builtin for this demo only
    try:
        raw = next(typed)
    except StopIteration:
        print(prompt)                  # the prompt shows, then the stream closes
        raise EOFError                 # exactly what Ctrl-Z (or Ctrl-D) raises
    print(prompt + raw)                # echo it, as a terminal would
    return raw


seconds = get_int("Length in seconds: ", low=1, high=3600)
print("Added a", seconds // 60, "min track.")

encore = get_int_or("How many encores? ", default=0, low=0, high=5)
print("Encores:", encore)

Length in seconds: 3:20
  '3:20' is not a whole number. Digits only - 200, not 3:20.
Length in seconds: -90
  -90 is below the minimum of 1.
Length in seconds: 9000
  9000 is above the maximum of 3600.
Length in seconds: 200
Added a 3 min track.
How many encores? 
  (input closed - falling back to 0)
Encores: 0

# 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. →

# guarded_playlist.py -- chapter 12 built the Playlist. This one hardens it.

class PlaylistError(Exception):
    """Base: anything this playlist refuses to do."""

class EmptyPlaylistError(PlaylistError):
    def __init__(self, name):
        super().__init__(f"{name!r} has nothing to play")
        self.name = name

class SongNotFoundError(PlaylistError):
    def __init__(self, name, title):
        super().__init__(f"{title!r} is not in {name!r}")
        self.name, self.title = name, title

class DuplicateSongError(PlaylistError):
    def __init__(self, name, title):
        super().__init__(f"{title!r} is already in {name!r}")
        self.name, self.title = name, title


class Song:
    def __init__(self, title, artist, seconds):
        if not isinstance(seconds, int) or seconds <= 0:
            raise ValueError(f"impossible length for {title!r}: {seconds!r}")
        self.title, self.artist, self.seconds = title, artist, seconds

    def __str__(self):
        minutes, secs = divmod(self.seconds, 60)
        return f"{self.title} - {self.artist} ({minutes}:{secs:02d})"


class Playlist:
    def __init__(self, name, songs=None):
        self.name = name
        self.songs = list(songs) if songs else []
        self.playing = None

    def __len__(self):
        return len(self.songs)

    def _find(self, title):
        for song in self.songs:
            if song.title == title:
                return song
        raise SongNotFoundError(self.name, title)

    def add(self, song):
        if any(s.title == song.title for s in self.songs):
            raise DuplicateSongError(self.name, song.title)
        self.songs.append(song)
        return self

    def remove(self, title):
        song = self._find(title)                   # _find raises if it is not here
        self.songs.remove(song)
        return song

    def play(self):
        if not self.songs:
            raise EmptyPlaylistError(self.name)
        self.playing = self.songs[0]
        return self.playing


# ---------- the caller: it catches, it never inspects ----------
def run(shelf, commands):
    for verb, arg in commands:
        try:
            if verb == "add":
                shelf.add(arg)
                result = f"added {arg.title}"
            elif verb == "remove":
                result = f"removed {shelf.remove(arg).title}"
            else:
                result = f"playing {shelf.play()}"
        except DuplicateSongError as e:
            print(f"  skip    {e}")
        except SongNotFoundError as e:
            print(f"  miss    {e}")
        except EmptyPlaylistError as e:
            print(f"  silence {e}")
        except PlaylistError as e:                 # anything of ours we forgot to name
            print(f"  refused {type(e).__name__}: {e}")
        else:
            print(f"  ok      {result}")


night = Playlist("Night drive")
run(night, [
    ("play", None),
    ("add", Song("Blinding Lights", "The Weeknd", 200)),
    ("add", Song("Titanium", "David Guetta", 245)),
    ("add", Song("Blinding Lights", "The Weeknd", 200)),
    ("remove", "Levels"),
    ("play", None),
    ("remove", "Titanium"),
])
print("shelf   :", [s.title for s in night.songs], "| now playing:", night.playing)

# a bad length never becomes a Song at all
try:
    Song("Broken", "Nobody", -50)
except ValueError as e:
    print("rejected:", e)

# and a caller who only cares that *something* of ours went wrong writes one line
try:
    Playlist("Empty").play()
except PlaylistError as e:
    print("one net :", type(e).__name__, "-", e)

  silence 'Night drive' has nothing to play
  ok      added Blinding Lights
  ok      added Titanium
  skip    'Blinding Lights' is already in 'Night drive'
  miss    'Levels' is not in 'Night drive'
  ok      playing Blinding Lights - The Weeknd (3:20)
  ok      removed Titanium
shelf   : ['Blinding Lights'] | now playing: Blinding Lights - The Weeknd (3:20)
rejected: impossible length for 'Broken': -50
one net : EmptyPlaylistError - 'Empty' has nothing to play