Reading errors and stack traces

Everyone has the same first reaction to a stack trace: eyes glaze over, stomach drops, want to close the tab. Twenty lines of red, half of them about files you’ve never seen, all of it ending in some inscrutable message like TypeError: Cannot read properties of undefined (reading 'map').

A stack trace is just the computer’s way of saying “I tried, and here’s exactly where I got stuck.” Claude reads that fluently. You don’t have to.

This lesson is about turning “oh no” into “oh, that’s all it was.”

What a stack trace actually is

Before we hand it off to Claude, a tiny demystification. A stack trace is the list of function calls that were in progress when the error happened — read top to bottom, with the most recent call at the top.

It looks intimidating because it’s printed for a machine, not a person: full file paths, line numbers, function names, sometimes call counts. But there are really only three things in there:

The error message — what went wrong, in one line.
The file and line — where it went wrong.
The chain of calls leading up to it — how the program got there.

Claude can extract all three from any trace, in any language, instantly.

The move

You hit an error. You stay calm. You copy the whole trace — all of it, including the empty lines and the parts you don’t understand — and paste it into Claude. The phrasing barely matters:

I'm getting this error. What does it mean and where do I look?

[paste the full trace here]

That’s it. Claude will:

Translate the error message into plain English.
Point at the file and line where it actually went wrong.
Often, look at that file directly and tell you what’s likely causing it.
Suggest a fix — or at least the next thing to check.

The “scary text” is now a paragraph.

Don’t trim it

The single biggest mistake beginners make is pasting only the last line. The bottom of the trace is where the error fired, but the top of the trace is where the error came from. Truncate it, and you’ve thrown away the part Claude needs most.

Paste the whole thing. Don’t editorialize. Don’t pick the line you think matters.

If the terminal scrolled and you only saw part of it, scroll back up and grab the whole block — usually the first blank line above is your start, and the prompt below is your end.

Errors that don’t have stack traces

Not every error comes with a polite stack trace. Sometimes you get:

A vague message in the terminal: “command not found” or “port 3000 already in use.”
A failed test with a diff between expected and actual.
A red squiggle in your editor with a tooltip.
A red box on a webpage when you tried something.

Treat all of these the same way: copy the text and the context — what you were doing when it happened — and ask Claude. Context is the multiplier.

I just ran `npm run dev` in this project and got this. What's wrong?

[paste the output]

Compare that with “npm doesn’t work” and you’ll see why context matters. (Anyone who has ever tried to help a friend with their computer over text knows the difference.)

The thing that trips people up

When the error is in a file from a library — not your own code — beginners panic. “I don’t know that library, how could I fix it?”

You don’t have to. Almost always, an error coming from a library means your code is using the library wrong. Claude will know this and tell you so:

“This error is from inside the react-query library, but it’s caused by your call in src/pages/home.tsx:42 — you’re passing undefined where a function was expected.”

That’s the answer you needed. The fix is in your file, not in the library’s. (You’re allowed to feel relieved.)

Why this lesson exists

Almost everyone who quits learning to code quits during an error. The wall of red feels like a personal failure. It isn’t — it’s just the machine being literal.

Errors aren’t punishments. They’re the most precise feedback you’ll ever get from a computer. Claude turns that precision into something a human can use.

After this lesson, an error should feel less like a wall and more like a door. A scary-looking door, sometimes. But a door.

What’s next

Sometimes the error isn’t in what’s there now — it’s in what changed. “This worked yesterday. What did I do?” That’s a git history question, and Claude is shockingly good at those too. Next lesson.