Facing up to mistakes

The thing that most separates people who keep going at programming is not how well they write. It is whether they can get themselves out when they are stuck. That is why this chapter sits before classes.

You will have met errors plenty of times already: NameError, TypeError, IndexError, KeyError. Here we sit down and read them properly. An error is the most accurate report Python can give you — where it happened and what happened, all in one place. Once you can read them, the time you spend stuck drops sharply.

First, the kinds of error. Learn to guess the cause from the name alone. NameError means you used a name it does not know, TypeError that you combined things of kinds that do not go together, IndexError that you reached past the end of a list, KeyError that you asked a dictionary for a key it does not have. Those four account for most of what a beginner produces.

Next, reading a traceback. When something goes wrong, Python tells you not just which line, but how it got there. With functions calling functions it gets long, but there is a knack: read it from the bottom. The real cause is down there.

When you cannot see the cause, there is print debugging. Drop a print somewhere suspicious and look at what the variables actually hold. It may feel primitive; professionals do it every day. Comparing expected and actual values helps narrow down the cause. Check the order of operations and conditions too.

The second half turns to getting ready for things going wrong. assert writes an assumption — "at this point, this must be true" — into the code, and stops on the spot if it is not. try and except wrap work that might fail so it can take another road instead of falling over. And raise is how you speak up yourself and say "this is not right".

By the end, an error stops being the end of the road. It becomes part of how you design.