The anatomy of an error message

Errors are structured, not noise

An error looks like a wall of text because nobody showed you which parts to read. There are only four, and they are in the same places every time.

TypeError: Cannot read properties of undefined (reading 'name')
    at BookingCard (/app/components/BookingCard.tsx:23:31)
    at renderWithHooks (/node_modules/react-dom/cjs/react-dom.js:14985:18)
    at mountIndeterminateComponent (/node_modules/react-dom/cjs/react-dom.js:17811:13)

The type. TypeError. A small vocabulary covers most of them and each points somewhere specific.

The message. What went wrong in words. Here: something was undefined and the code asked it for .name.

The stack. Where it happened, innermost first. The first line naming your file is the one that matters. Lines mentioning node_modules are the library’s internals, and reading them is nearly always a waste.

The position. 23:31 is line 23, character 31.

Four pieces, and the third is the one people miss because they stop reading at the first line.

The error types worth recognising

TypeError: Cannot read properties of undefined: you have something you thought was an object and it is not there. Usually data that did not load, or a field with a different name than you expected. The most common runtime error in JavaScript by a wide margin.

ReferenceError: x is not defined: a name that does not exist in scope. A missing import, or a typo, or code using a browser API on the server.

SyntaxError: the file cannot be parsed at all. Usually a missing bracket, and the reported line is often just after the real problem.

ECONNREFUSED: nothing is listening at the address something tried to reach. Your database is not running, or the URL is wrong, or the port is.

Module not found: an import that does not resolve. A missing dependency, a typo in the path, or wrong capitalisation, which works on your Mac and fails on Linux.

Hydration failed in React: the HTML the server produced and the HTML the browser produced disagree. Almost always something non-deterministic in a component: Date.now(), Math.random(), or a value read from the browser during a server render.

EADDRINUSE: the port is already taken by a server you started earlier and forgot.

Read from the bottom of your own frames

When several of your own files appear in the stack, the top one is where it crashed and the lower ones are how it got there. Both matter. The crash location tells you what broke; the caller tells you what fed it the bad value, and that is usually where the actual mistake lives.

A null booking crashing in BookingCard was probably created by a query in page.tsx that returned nothing. Fixing BookingCard to tolerate the null is sometimes right and sometimes hides the real problem, which is that the query is wrong.

Server errors versus browser errors

Same vocabulary, different places to look.

A browser error appears in the devtools console. The user sees a broken screen and you see red text.

A server error appears in your terminal locally, and in your host’s log viewer in production. The user sees a 500 page with no detail, deliberately: the message is hidden because error messages leak information about your system. So a user reporting “it says something went wrong” has given you all they have, and the actual error is in your logs.

This is why the deployment lesson insists you find your host’s log page before you need it.

What to include when you pass it on

A good error report to a model or a human has five parts, and takes thirty seconds:

1. The full error, first three lines minimum, uncut.
2. The first line of the stack that names your own file.
3. What you did immediately before it.
4. Whether it happens every time.
5. What you already tried.

The fifth stops you receiving the same suggestion twice, which is otherwise the most common way these conversations go in circles.

The errors that lie

Two cases where the message points at the wrong place.

A missing bracket reports a line well after the real one, because the parser only notices something is wrong when it reaches something impossible.

A crash inside a library reports the library’s file. The cause is almost always the value you passed in, one or two frames down the stack in your own code. Look there first, and resist the urge to conclude that a widely used library is broken.