How to Read an Error Message: Stack Traces Explained for Beginners

Start with three things: the error type, the message that follows it and the file and line number where it happened. Those three pieces answer what went wrong, roughly why, and where to look. Everything else in the output, including the long list of lines called a stack trace, is supporting evidence that tells you how the program got there.

That sounds tidy, yet most beginners do the opposite. They see a block of red text, feel a jolt of alarm and go straight back to the code, guessing. Reading the message slowly is faster almost every time.

Anatomy of an error message

Take a typical message from a Python program:

TypeError: can only concatenate str (not "int") to str

• TypeError is the category. It says a value of the wrong type was used.
• The text after the colon is the detail: the program tried to join a piece of text and a number with a plus sign, which Python refuses to do automatically.
• Just above it, the output names the file and line number, and often reprints the offending line.

Other languages phrase things differently, but the ingredients are nearly always the same: a type, a description and a location.

What a stack trace shows

Programs are built from functions that call other functions. When something fails deep inside that chain, the stack trace lists every call that was active at the moment of the crash, like a trail of breadcrumbs from the starting point to the failure. If the idea of one function calling another is still new, the explainer on functions, parameters and return values covers it.

Which end to read first

Languages print the trail in different orders, and knowing this saves a lot of confusion:

• Python prints its traceback with the most recent call last. The actual error sits at the bottom, so read from the bottom up.
• Java and JavaScript usually print the error first, followed by the calls with the most recent at the top. Read from the top down.

In either case, scan for the first line that points to a file you wrote. Lines from libraries and the language itself are usually not where the mistake lives; they are where your faulty input finally caused trouble.

The three kinds of error

Logic errors are the trickiest because there is no message at all. When exactly each kind gets reported also depends on whether the language is compiled ahead of time or interpreted, a difference explained in compiled vs interpreted languages.

A calm debugging routine

Debugging simply means finding and fixing the cause of a bug, the programmer's word for any defect. A repeatable routine beats inspiration:

1. Read the whole message once, slowly. Note the type, the detail and the location.
2. Go to the line, then look one line above. Syntax errors are often reported on the line after the real slip, such as an unclosed bracket.
3. Check your assumptions about values. Print the variables involved just before the failing line, or pause there with a debugger, and compare what they hold with what you expected.
4. Shrink the problem. Remove or comment out code until you have the smallest piece that still fails. The cause is usually obvious at that size.
5. Search the exact message. Copy the error text, leaving out your own file and variable names, and look it up. Common errors have been explained many times.
6. Make a single edit per attempt. Several simultaneous edits make it impossible to know which one helped.

A good editor helps with several of these steps: it underlines syntax problems as you type and offers a debugger that can stop at a chosen line. The guide to IDEs and code editors describes those tools.

Habits that make errors less painful

• Run your code often, after small changes, so a new error almost certainly comes from the last few lines you touched.
• Keep the error output visible instead of clearing the terminal straight away.
• Write down errors that took a while to solve, with the fix. Patterns appear quickly.
• Treat warnings seriously, too; they often predict tomorrow's errors.

Questions beginners ask

Why does the error point to a line that looks fine?

The line reported is where the program noticed the problem, not always where it began. A bad value created earlier may only cause a crash several calls later, which is exactly why the stack trace is there.

Is getting lots of errors a sign I am bad at this?

No. Errors are a normal, constant part of programming at every level. Learning to read them calmly is one of the habits that schools and courses try to build early, as described in the piece on why coding belongs in the classroom.