Learning to read an error message

The most common thing I watch happen in a beginner's terminal is this. Something goes wrong, twenty lines of red appear, and the student scrolls past all of it to ask me what is wrong. They did not read it. Often they did not even look.

That is not laziness. It is a reasonable response to a wall of text that arrives styled like an alarm. But it is the single habit standing between a lot of students and being able to work on their own, so it is worth breaking early.

An error is an answer

A stack trace is the program telling you exactly where it stopped and what it was holding at the time. That is information you would otherwise have to guess at. Most of the twenty lines are the call path, which you can ignore at first. Three things matter.

The type of error. The message. The first line in the trace that names a file you wrote.

TypeError: Cannot read properties of undefined (reading 'name')
    at renderUser (app/components/user.tsx:14:22)
    ...twenty more lines you can skip

That says: on line 14 of a file I wrote, something I expected to be an object was undefined. It has told me the file, the line, the character, and the exact assumption that turned out to be false. Nothing about that requires interpretation. It requires reading it.

Read from the top of your own code

Traces are usually printed with the deepest call first, and the deepest call is often inside a library. The line you want is the highest one that points at a path you recognise. Start there.

If the message names something as undefined, the useful question is not why it is undefined here. It is where it was supposed to get set, and whether that ever ran.

Errors that do not look like alarms

When I built EasyLang, a small language with Hindi keywords aimed at students in exactly this position, the error output got more attention than any other part of it. The playground prints errors at the same size and in the same colour as ordinary output. No red, no warning triangle.

The reason is the habit above. If a tool treats every mistake as an emergency, a student learns to avoid mistakes, and avoiding mistakes means not trying things. There is a longer note on that build in the notes section of this site.

The error is not the tool refusing you. It is the tool telling you the one thing it knows that you do not.

One habit to build

Before you paste it into a search box or ask anybody, read the message out loud in your own language and say what you think it means. You will be right more often than you expect. When you are wrong, you will at least be wrong about something specific, which is a much better question to bring to somebody.