Reading Error Messages Instead of Panicking
Okay so here's the thing. Your code is going to break. Not might. Will. Today, probably, if you haven't already had it happen. And the second most important skill in this whole class, right after "break the problem into stupid-small steps," is not freaking out when a wall of red text shows up.
I want to be straight with you about something first. When beginners see an error, the instinct is to feel like they did something shameful. Like the computer caught them being bad at this. That's not what's happening. An error message is the computer being weirdly, almost annoyingly helpful. It's telling you exactly where it got confused and usually exactly why. Most of the job, once you get past the beginner stuff, isn't writing code that works on the first try. It's reading what went wrong and fixing it. So getting good at reading errors basically IS getting good at coding. That's most of the whole skill, honestly.
What's actually in there
Python error messages look intimidating because they're long. But they've got a pattern, and once you see the pattern it stops being scary.
At the bottom, you'll see the actual error. Something like:
`` NameError: name 'total' is not defined ``
That bottom line is the headline. Read that first. Always. Not the stuff above it, not yet.
Above that, you'll see a "Traceback," which is Python showing you the path it walked to get to the crash. It'll point at a line number. Go to that line number in your file. That's almost always where the problem lives, or one line before it.
So your process, every single time, is:
- Read the bottom line first.
- Find the line number it's pointing at.
- Look at that line and the one right before it.
- Ask "okay, what is Python confused about here."
That's it. That's the whole method. Super simple, not always super easy, but simple.
The greatest hits
You'll see the same handful of errors over and over as a beginner. Get familiar with these and half your panic goes away because you'll recognize them like an old song.
NameError — you used a variable that doesn't exist yet, usually because you typo'd it or you're using it before you created it. I named a variable list once, back when I was starting out, because it was, you know, a list. Broke everything downstream and it took me an hour to figure out why, because Python already uses that word for its own stuff. Learned that one the loud way.
SyntaxError — you're missing a colon, a parenthesis, a quote mark. Python is picky about this stuff and it will tell you almost exactly where the sentence broke down.
IndentationError — your spacing is off. Python cares about this in a way most languages don't. Fix the spacing, try again.
TypeError — you're trying to do something to a value that doesn't make sense for that type. Adding a number to a piece of text, that kind of thing.
You don't need to memorize what each one means right now. You need to know that reading the bottom line and the line number will get you there nine times out of ten.
The print statement thing
Okay so here's my actual confession. When I can't figure out what's going on, my first move isn't some fancy debugging tool. It's sticking a print() statement in the middle of my code to see what a variable actually holds at that moment. My son Jared watched me do this once, mid-debug, and said "oh, you're using print statements like a caveman." He wasn't wrong. I still do it. It works. It's fast, it's honest, and it shows you exactly what your program thinks is true at that point in time, which nine times out of ten is different from what YOU think is true. That gap is usually the whole bug.
So when an error message isn't telling you enough on its own, throw a print statement above the line that's breaking. Print out the variable. Look at what it actually is versus what you expected. The mismatch is your answer.
The part where you have to slow down
The other thing that gets beginners is speed. You see red text, you panic a little, and you start changing things fast, hoping something sticks. Don't. Read the message. Actually read it, the words, not just the vibe of "uh oh." Then go look at the line. Then make ONE change. Then run it again. If you change five things at once you'll never know which one fixed it, or which one broke something new.
Try this at home
Open any script you've written for this class. On purpose, break it. Delete a colon. Misspell a variable name. Remove a closing parenthesis. Run it, read the error, fix it, run it again. Do that four or five times with different mistakes. You're building a mental library of "oh, THIS is what that error looks like," so when it happens for real, by accident, you already recognize the shape of it.
Before next time: find an error message from something you wrote earlier in this course, and see if you can explain out loud, to nobody in particular, exactly what it was telling you. If you can't, bring it in and we'll read it together.