🛟 Errors & Exceptions, lesson 1 of 6
Reading tracebacks
Decode Python's error reports to find bugs fast.
8 min
1 exercise
2 quizzes
0/3 solved
Getting Python ready… examples can run in a moment.
Every programmer sees errors all day long. When Python hits a problem it can't handle, it stops and prints a traceback: a report of what went wrong and where.
Errors aren't failures. They're clues, and learning to read them is one of the most useful skills you can have.
A typo becomes a NameError
Read the last line first. Python even suggests the fix ("Did you mean..."). Correct the typo and run it again.
Read a traceback from the bottom up:
- Last line: the exception type (like
NameError) and a message explaining it. - Just above: the line number and the line of code that failed.
- Anything printed before the error still shows. Python runs line by line until it crashes.
Which part of a traceback should you usually read first?
Errors inside functions. When the crash happens in a function, the traceback lists every call on the way there, most recent call last. The bottom entry is where it broke; the entries above show how the program got there.
Following the call chain
The first report works. The second crashes inside
average because len([]) is 0. Spot the chain:
module → report → average.
A syntax error stops everything
Add the missing : after if 3 > 2 and run it again. Now both lines print.
What gets printed before the traceback appears?
Fix the receipt
This receipt program has two bugs. Run it, read the
traceback, fix the first bug, then run it again to find
the second. It should print Total: 7.5.