Reading an Error Message

Error messages have a reputation for being mean. They arrive in red, they use jargon you have never seen, and they pile up right when something is already going wrong. But here is the truth that changes everything: an error message is not scolding you. It is a precise statement from the computer about exactly where it got confused. Learning to read that statement is one of the most valuable skills you can build.

The Anatomy of an Error

Most error messages share a structure, even across different programming languages and tools. Once you know the structure, any error becomes easier to read. Error Type — the category of problem. Common examples: SyntaxError (you typed something the language cannot parse), TypeError (you used the wrong kind of value), ReferenceError (you used a name that does not exist), and FileNotFoundError (a file you asked for is not where you said it was). Error Message — a short description of the specific problem in plain-ish English. Often one sentence. Stack Trace — a list of locations in your code, from where the error happened back to what triggered it. It looks like a trail of breadcrumbs pointing to the scene of the problem. Line Number — almost always present, and almost always the most useful piece: this is where the computer stopped and said 'I cannot continue.'

Worked example: Imagine you are building a simple web page that displays a student's score. You run it and see: TypeError: Cannot read properties of undefined (reading 'score') at displayResult (app.js:42) at submitQuiz (app.js:28) Step 1 — Error type: TypeError. Something was used as if it had properties, but it was undefined. Step 2 — Message: 'Cannot read properties of undefined (reading score).' Something you expected to have a 'score' property turned out to be undefined. Step 3 — Stack trace: the problem showed up in displayResult at line 42. That function was called by submitQuiz at line 28. Step 4 — Go to line 42. You find: return student.score. The variable student is undefined. You look at where student comes from and realize you never passed it to displayResult. That is the bug. The error told you everything. You just had to read it.

When the Error Points Somewhere Confusing

Sometimes the line the error points to is not where the real problem is — it is just where the problem became visible. A variable might be set incorrectly on line 10, but the error only appears on line 40 when you try to use it. This is why the stack trace matters. If line 40 looks fine to you, follow the trace up to the function that called it, then up again. The real cause is usually one or two steps earlier. AI tools are especially good at this kind of trace-following. If you paste an error message with its full stack trace into a conversation with an AI, it can often identify not just where the crash happened but where the problem originated — a different skill than just reading the bottom of the trace.