Read the Actual Error
Reads what the error really says — the file, the values, the chain — before matching it to a bug you have seen before.
When to reach for it
The second an error appears and the temptation is to apply the fix that worked last time for something that looked similar.
What changes
- The agent quotes the error text and the relevant stack frames instead of paraphrasing them, so you can check the reading yourself.
- The first frame belonging to your own code gets identified, so the fix does not land on a line inside a dependency.
- Wrapped and chained errors get unwrapped to the original cause, so you fix the failure rather than the thing that noticed it.
- Every concrete detail in the message — a path, a null field, a status code, a type name — gets checked against reality before it is explained away.
- Fixes stop landing in the wrong file because a message resembled a familiar one.
Pairs with
Read the Actual Error
Errors are nearly always specific. Familiarity is what makes them look generic. Read this one.
1. Quote it, do not summarize it
Copy the message exactly and in full. Errors get truncated, reworded and tidied on the way to being explained, and the part that gets removed is often the part that mattered.
2. Take the message apart
Every concrete thing in it is a claim you can check:
- A path or module name — does that file exist, at that path, right now?
- A value — is the empty thing the thing you assumed it was?
- A type name — is that the type you believed was there?
- A number: status code, line number, port, exit code, count.
- The verb: could not find, could not parse, refused, timed out, denied. Those mean very different things and lead to different files.
Check the claims against reality. One of them is usually already false.
3. Find your own first frame
Read down the stack, past framework and library frames, to the first line in code you control. That is where to look, even when the message points somewhere else. Note the frame above it too: it tells you what was being attempted when things went wrong.
4. Unwrap the chain
Look for nested causes and aggregated errors. The outermost message describes who noticed. The innermost describes what happened. Fix the innermost.
5. Say what it means before changing anything
One sentence in your own words, containing the file, the value and the condition: "In the import handler, row twelve has no email field, and the validator rejects the whole batch rather than the row."
If you cannot write that sentence, you have not read the error yet. Print the actual value and run it again.
Rules
- Do not fix an error that resembles one you know without confirming it is the same one. Similar messages come from different causes far more often than the reverse.
- Do not act on the top stack frame when it is inside a library. It reports where the problem was noticed, not where it was caused.
- Do not silence the error to see what happens next. The next error will be a consequence of the one you hid.
- Do not trust a line number from code that was not rebuilt. Confirm that what you are reading is what actually ran.