When Things Go Wrong on Purpose

Every red wall of text Python shows you looks the same at a glance, and treating them as one category costs you time later. A SyntaxError happens before your program runs a single line — Python read the whole file, could not make sense of its grammar, and refused to start at all.

$ >>> def greet(name)  File "<stdin>", line 1    def greet(name)                   ^$ SyntaxError: expected ':'

Everything else — KeyError, TypeError, ZeroDivisionError, the ones the picker below shows — is an exception. An exception can only happen after the program has started running, on a line that parsed correctly but turned out, at that moment, to be impossible: a key that was never there, a division by a number that happened to be zero. The distinction matters because only exceptions can be caught with try and except. A SyntaxError in the file you are running has already stopped the program before any except clause of yours gets a chance to run.

The last line of a traceback names the exception and the message — that is what actually went wrong. The lines above it, read bottom to top, are the chain of calls that led there: the line your own code was on comes first, then whatever called that, and so on outward.

Here is one with more than one frame in it, which is where the bottom-up habit actually earns its keep.

CATALOGUE = {"bread": 3.2, "eggs": 4.5} def price_for(item):    return CATALOGUE[item] def total(cart):    running = 0    for item in cart:        running += price_for(item)    return running total(["bread", "eggs", "kombucha"])

Try itRun it for the traceback, then add a price for "kombucha" and print the total.

$ Traceback (most recent call last):  File "shop.py", line 12, in <module>    total(["bread", "eggs", "kombucha"])  File "shop.py", line 9, in total    running += price_for(item)               ^^^^^^^^^^^^^^^  File "shop.py", line 4, in price_for    return CATALOGUE[item]           ~~~~~~~~~^^^^^^$ KeyError: 'kombucha'

Start at the bottom: KeyError: 'kombucha'. Move up one frame: the crash happened inside price_for, on the line that looks up CATALOGUE[item]. Move up again: price_for was called from line 9 inside total, which was itself called from line 12, at the bottom of the file. Reading top to bottom instead tells you the same thing backwards — you would wade through two frames you do not need yet before reaching the one line that actually matters.

try and except let a program recover from an error instead of crashing — but only if you catch the specific exception you actually anticipated.

$ >>> try:$ ...     price = prices["mango"]$ ... except KeyError:$ ...     price = 0$ ...$ >>> price$ 0

A single except can also name more than one exception, as a tuple, when the same recovery applies to either: except (KeyError, IndexError): runs the same block whichever of the two happens. Reach for that instead of a bare except the moment you are tempted to write one.

Most examples stop at try and except, which makes the other two clauses look optional. They are not decoration — each one runs at a different, precise moment, and reaching for the wrong one is a real source of bugs.

catalogue = {"bread": 3.2, "eggs": 4.5}item = "milk" try:    price = catalogue[item]except KeyError:    print(f"No such item: {item}")else:    print(f"{item} costs {price}")finally:    print("Checked catalogue.")

Try itChange item to "eggs" and see which clauses run now.

1. 1

   try — the code that might fail

   Keep it to the smallest block that can actually raise the exception you are guarding against. Wrapping more than that risks silently catching a bug you never meant to.

2. 2

   except — runs only if try raised that exception

   This is where you recover: log it, substitute a default, or tell the user. It never runs if try succeeded.

3. 3

   else — runs only if try succeeded

   Code here runs when nothing went wrong, and an exception raised inside else is not caught by the except above it. It keeps your success-path code from being accidentally shielded by your own error handling.

4. 4

   finally — always runs, success or failure

   Used for cleanup that has to happen either way, like closing a connection or releasing a lock. It runs even if the except block re-raises the error.

Put the print inside try, right after fetching the price, instead of in else, and a bug in that print statement itself — a typo in the variable name, say — gets reported as though it were a KeyError, when it never was one. else exists specifically to stop that.

You can trigger an exception deliberately with raise, which is often clearer than letting bad input travel deep into a program before it fails on its own, somewhere confusing.

$ >>> def set_age(age):$ ...     if age < 0:$ ...         raise ValueError("age cannot be negative")$ ...     return age$ ...$ >>> set_age(-5)$ ValueError: age cannot be negative

Failing loudly and immediately, at the exact line where the impossible value appeared, is far easier to debug than a program that accepts -5 quietly and produces a nonsensical answer four functions later.

The condition you check does not have to be this simple. Validate every assumption the rest of the function depends on at the top, before any of the real work runs — that way a bad call fails on its very first line instead of partway through a calculation that no longer makes sense.

ValueError is honest but generic — catching it also catches every other ValueError anywhere else in the program, for reasons that have nothing to do with the one you meant. A custom exception class costs one line and buys you something to catch precisely.

class InsufficientFundsError(Exception):    pass def withdraw(balance, amount):    if amount > balance:        raise InsufficientFundsError(            f"cannot withdraw {amount}, balance is {balance}"        )    return balance - amount try:    print(withdraw(50, 75))except InsufficientFundsError as error:    print(f"Blocked: {error}")

Try itChange 75 to 20 and run it again.

Inheriting from Exception is enough — pass, with nothing else, is a complete class, because Exception already knows how to store the message you pass it and print it back. Now except InsufficientFundsError: catches exactly this failure, and nothing that merely happens to share a message with it.