Reading an Error Message
You Do Not Need to Understand It
An error message is not written for you, and you do not need to understand it for it to be useful. It needs to be captured accurately and passed on. That is the entire skill, and it is enough. Most messages contain three things worth spotting. A short statement of what went wrong. A file name and a line number saying where. And a long list underneath, showing the chain of steps that led there. The top line is usually the informative one; the long list is mostly noise for your purposes. Read "cannot read property name of undefined" and think "something expected a thing that was not there". That is a completely respectable level of understanding for what you are doing.
- Capture accurately beats understand deeply — you need the text, not the theory
- The top line says what; a file and line number says where
- The long list below is the path it took, and is mostly noise to you
- A rough sense of the shape of the error is enough to act on
Copy the Whole Thing
Paste the entire message, not a summary of it. Retyping "it says something about undefined" throws away the file name, the line number and the exact wording. Those are precisely the parts that turn a guess into a targeted fix. Select it, copy it, paste it. A screenshot will do if you cannot select the text, but selectable text is better, because it can be searched. Include the lines above and below the part that looks important. The interesting detail is often just outside the bit that caught your eye. This one habit — paste it all — probably saves more time than anything else in this module, and it requires no understanding whatsoever.
- Paste the complete message including file names and line numbers
- Never paraphrase an error; the exact wording is the useful part
- Grab a few lines either side of the part that looks relevant
- Selectable text beats a screenshot because it can be searched
Where the Messages Hide
Sometimes nothing appears on screen and the page simply does not work. The message usually still exists, just somewhere you have not looked. Browsers keep a hidden panel, often called developer tools or the console, which records errors happening in the page. Opening it is a menu item, not a technical act. Tools that run your code will have a log or output area, showing what happened as it ran. Hosted builders keep build logs and runtime logs. Learn where these live in whatever you are using, and find them early, while nothing is on fire. "Nothing happened" is a much weaker report than the two lines of red text sitting in a panel you did not know existed.
- Browsers keep a console panel that records errors invisible on the page
- Editors and builders keep logs of what happened while running
- Find these places once, early, while nothing is on fire
- "Nothing happened" almost always means "I have not found the message yet"
Some Errors Are Not Errors
Not everything red is a problem. Consoles are full of warnings, notices and complaints from unrelated parts of a page: a missing icon, an outdated setting, something from an advert or a browser extension. These sit there permanently and have nothing to do with your problem. The useful discipline is timing. Reproduce the problem while watching, and pay attention to what appears at that moment. Anything that was already there before you clicked is background noise. This one distinction saves a lot of wasted effort. Without it you chase warnings that have sat there harmlessly since the day the project was created, and will still be there when everything works.
- Warnings are not failures; plenty of them are permanent and harmless
- Clear the panel, reproduce the problem, and read what appears at that moment
- Messages present before you acted are background noise
- Chasing pre-existing warnings is a classic beginner time sink
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.