Errors and exceptions

Reading a traceback

An error that happens while a program runs is called an exception. If nothing handles it, Python stops and prints a traceback. That's a report of what went wrong, and of the chain of calls that led there. Think of a package's tracking history: the last entry tells you where it got stuck, and the ones above show the route it took. Run this and read the result:

def conversion_rate(conversions, clicks):
    return conversions / clicks

def report(name, conversions, clicks):
    rate = conversion_rate(conversions, clicks)
    print(name, rate)

report("Spring Sale", 301, 5470)
report("Holiday Teaser", 0, 0)

Read a traceback from the bottom up:

1. The last line names the exception type and gives a message: ZeroDivisionError: division by zero.
2. The line above it shows where it happened: line 2, inside conversion_rate.
3. The lines above that show how the program got there: line 9 called report, which called conversion_rate on line 5.

Notice the first report printed before the crash. Everything before the failing line ran normally. Python stops at the failure.

On your own computer, tracebacks start with Traceback (most recent call last): and include file names, but they read the same way. The academy shortens them to the lines of your code.

The usual suspects

A handful of exception types cover most of the errors you'll meet:

SyntaxError is different from the rest. Python checks the whole file before running anything, so a syntax error means no line runs. Every other exception happens partway through, when the bad line is reached.

budgets = [5000, 2000, 8000]
print(budgets[3])

Handling errors with try and except

When you expect a particular failure and know what to do about it, wrap the risky code in try and say what to do in except:

raw_values = ["120", "95", "n/a", "300", ""]

total = 0
skipped = 0
for raw in raw_values:
    try:
        total += int(raw)
    except ValueError:
        skipped += 1

print("Total clicks:", total)
print("Skipped:", skipped)

Think of it as a safety net under one particular trick. Python runs the try block. If a ValueError happens anywhere inside it, Python jumps straight to the except block instead of crashing, then carries on after it.

Any other kind of exception still crashes the program. That's what you want: you only handle the failure you planned for.

To see the error itself, give it a name with as:

for raw in ["42", "forty"]:
    try:
        print(int(raw))
    except ValueError as e:
        print("Couldn't read", repr(raw), "-", e)

total = 0
for raw in ["5", "x", "7"]:
    try:
        total += int(raw)
    except ValueError:
        total += 100
print(total)

else and finally

Two optional blocks complete the picture. else runs only if the try block raised nothing. finally runs no matter what, even after a return:

def parse_budget(text):
    try:
        amount = float(text)
    except ValueError:
        print("Not a number:", text)
        return None
    else:
        print("Parsed", amount)
        return amount
    finally:
        print("Done checking", repr(text))

parse_budget("2500")
parse_budget("lots")

How often you'll use each:

• try/except: constantly.
• else: now and then. It keeps the try block small, so you don't catch errors from code that wasn't risky.
• finally: for cleanup that must happen, such as closing a connection. For files, Python's with statement does the cleanup for you, as you'll see in the files lesson.

Raising your own errors

When a function gets input it can't sensibly use, the clearest thing it can do is stop with a message. That's raise:

def set_budget(amount):
    if amount <= 0:
        raise ValueError(f"Budget must be positive, got {amount}")
    return amount

print(set_budget(500))
print(set_budget(-20))

Failing loudly and early beats quietly carrying on with nonsense, like a negative budget that turns into a negative bid three steps later. Code that calls set_budget can still catch the ValueError if it knows how to recover.

Don't catch everything

It's tempting to wrap a big block in except Exception: (or a bare except:) so the program "never crashes". Here's why that backfires:

prices = [28, 64, 18]
try:
    total = sum(prices)
    average = total / len(prise)   # typo: should be prices
except Exception:
    average = 0
print(average)

The typo raised a NameError. The broad except swallowed it, and the program printed a confident, wrong 0. A crash would have shown you the bug in seconds. Silent wrong answers can survive for months.

The rule: catch the specific exceptions you expect and can handle. Let everything else crash where you can see it.

The one common exception is the top of a long batch job, say one that processes 10,000 rows. There you may catch broadly, so one bad row doesn't stop the rest. Even then, record which rows failed and why.

For AI work: when you call an LLM API you'll catch specific failures such as rate limits and timeouts and retry them, while programming mistakes should still crash.

answers = ["8", "10", "seven", "", "9", "11", "6"]

def parse_score(text):
    score = int(text)
    if score < 0 or score > 10:
        raise ValueError(f"{score} is outside 0-10")
    return score

scores = []
problems = []
for a in answers:
    try:
        scores.append(parse_score(a))
    except ValueError as e:
        problems.append(repr(a) + ": " + str(e))

print("Valid scores:", scores)
print("Average:", round(sum(scores) / len(scores), 2))
for p in problems:
    print("Skipped", p)

Keep the try small

Put only the line that can fail inside try. A long block catches errors you never meant to catch, and hides them.