We are by now all familiar with the dreaded Traceback (most
recent call last):. The sign that something has gone wrong, that
your late night just got later, your assignment is rapidly becoming
overdue, and that there's not nearly enough coffee left in the jug!
Well, believe it or not, the messages python prints are there to help
you, as long as you are willing to read and understand them.
First we need to understand to concept of the call stack. When we are running our python program, the execution point moves around, from top to bottom, branching at if statements, looping with while or for statements, or jumping inside functions... but this causes issues. If an error occurs in our main program block, it's easy to track down where it is by line number alone. There's generally only one way for execution to reach that line. But in a function, which can be called from many places within our program, including itself or other functions, knowing that the error occurred on a line in a particular function definition doesn't help us understand how the flow of execution led up to the error. Enter the call stack! Every time a function is called, python pushes it onto something called the call stack. Think of a stack like getting into the elevator in a crowded mall. You get in first, and as more people enter the elevator, you are forced to the back. When you arrive at your floor, the last person in, now being closest to the doors exits first. If you want to get out in the middle somewhere, everyone who got in after you must briefly step out, to let you out, then go back in. This is exactly what happens with the call stack. As functions are called, their names are placed on the stack, and as they return, their names are removed. The Traceback presents us with the list of called functions (from the first called to the most recent called [most recent call last]), telling us the file where the call occurred, the line in that file, and the name of the function the call was made from if any (otherwise '?'). On the next line slightly indented it tells us the name of the function called. So looking at the following traceback,
Traceback (most recent call last):
File "test.py", line 25, in ?
triangle()
File "test.py", line 12, in triangle
inc_total_height()
File "test.py", line 8, in inc_total_height
total_height = total_height + height
UnboundLocalError: local variable 'total_height' referenced before assignment
We see that execution started in the file test.py and proceeded to line 25, where the function 'triangle' was called. Within the function triangle, execution proceeded until line 12, where the function 'inc_total_height' was called. Within 'inc_total_height' and error occurred on line 8.
The last line (or sometimes two lines) of the traceback describe what actually went wrong. In python, all errors are given a class, e.g. input/output error, undefined variable, index out of range, etc... These classes are given names that are one word without spaces, and which can in fact be used within python code (but we'll get to that later). The class name of the error, describing roughly what type of error occurred, is printed first, and then everything following the colon (':') is further description of the actual variables, expressions, and statements involved in the error, and what they were doing. So we can tell from the above example that the class was 'UnboundLocalError' and that the local variable 'total_height' was referenced (evaluated) before a value was assigned to it.
Learning the meaning of the class names comes with time, but the description following is usually sufficient to point you in the right direction. At least now you can track down exactly what line is causing the problem, and how the program got there.