How to read an error message
Error messages look hostile, but they usually tell you exactly what went wrong and where. A four-step habit for reading them calmly.
Published
New programmers often see an error, feel stuck, and start changing code at random. Experienced developers do something different: they read the message. Here is the habit.
1. Find the actual message
Long errors usually have a lot of noise. Look for the line that names the type of error and a short description — for example:
TypeError: Cannot read properties of undefined (reading 'name')
The type (TypeError) tells you the category. The description tells you the specific problem: something you expected to be an object was undefined, and the code tried to read .name from it.
2. Find where it happened
Below the message is usually a stack trace: a list of places the program was when it failed, most recent first. Find the first line that points to your file rather than a library:
at renderProfile (src/profile.js:14:22)
That means file src/profile.js, line 14, column 22. Open it.
3. Ask "what value was wrong?"
On that line, find the expression the message describes. If it says it cannot read name of undefined, look for something.name and ask: why is something undefined here? Print it, or use a debugger, one line before the failure.
4. Change one thing, then run again
Fix the cause you found — not the symptom — and run the program again. If the error changes, read the new one. A new error is progress.
Searching for help
If you still need to search, copy the type and description, but remove anything specific to your project (file names, variable values). Read answers critically: check that the situation matches yours before copying a fix.
The habit takes a few weeks to build. After that, most errors take minutes rather than hours.
Want to practise this properly?