Reading a traceback

01 / 07

The wall of text that comes with an error

When something goes wrong, Python gives you more than the last line: it also shows how it got there. That block of text is called a traceback — the trail it followed.

It looks forbidding, but the places you read are fixed. There is no need to take in all of it.

This lesson gives you three of them, and no more.

02 / 07

A real one

Run the code below and this is the traceback you get.

Traceback (most recent call last):  File "/lib/python314.zip/_pyodide/_base.py", line 523, in eval_code    .run(globals, locals)     ~~~^^^^^^^^^^^^^^^^^  File "/lib/python314.zip/_pyodide/_base.py", line 357, in run    coroutine = eval(self.code, globals, locals)  File "<exec>", line 2, in <module>IndexError: list index out of range

Eight lines of it — and only the bottom two have anything to do with you. The rest is the machinery this app uses to run your code.

fruits = ["apple", "orange", "grape"]print(fruits[5])

Result

IndexError: list index out of range

03 / 07

One: only look below exec

Find the line that says File "<exec>". Everything from there down is about the code you wrote.

The _pyodide/_base.py lines above it belong to the files this app uses to run Python. They have nothing to do with your code, so skip the lot.

<exec> is the mark for "the code being run right now". That is the name your program goes by.

04 / 07

Two: the last line is the conclusion

Read the very last line. That is where kind: body sits.

The IndexError and KeyError from the last lesson turn up here. What happened is almost entirely in that one line.

So when a long traceback appears, run your eye to the bottom first. Read from the top and you will wear yourself out on lines that do not concern you.

prices = {"apple": 120}print(prices["grape"])

Result

KeyError: 'grape'

05 / 07

Three: line N is the line number

The line N on the <exec> line is the line number in your code.

File "<exec>", line 2, in <module> means the error happened on line 2. That is where you go and look.

The in <module> on the end means "out at the top level, not inside a function". When it does happen inside a function, the name of the function goes there instead.

06 / 07

Functions calling functions make it longer

When an error happens inside a function, several <exec> lines stack up. The code below gives you this.

  File "<exec>", line 7, in <module>  File "<exec>", line 5, in calculate  File "<exec>", line 2, in divideZeroDivisionError: division by zero

They are in the order they were called. Line 7 called calculate, line 5 of that called divide, and the division on line 2 failed.

So the bottom <exec> line is where the error actually happened. The ones above it are the road that led there.

def divide(a, b):    return a / bdef calculate(x):    return divide(x, 0)print(calculate(10))

Result

ZeroDivisionError: division by zero

07 / 07

Read from the bottom up

To put it together, you read a traceback from the bottom upwards.

the last line tells you what happened
the <exec> line just above it tells you where it happened
if that is not enough, keep going up to see how it got there

That much gets you to the cause of most errors.

There is one case it cannot help with: when nothing errors but the answer is wrong. The next lesson is about what you do then.