How to Debug a Runtime Error from a Stack Trace with Claude Code
Turn a production stack trace into a located, explained bug by handing Claude Code the trace and the relevant files.
A stack trace from a crash is a map, but reading it under pressure is slow. Claude Code can follow the frames, find the line that threw, and explain the condition that triggered it. The goal is a precise root cause and a fix you understand, not a try-catch slapped over the symptom.
What you need
- Claude Code in the affected repo
- The full stack trace, including the error message and file frames
- The input or request that triggered the crash, if you have it
Step 1: Paste the full trace
Give Claude the complete trace, not a screenshot of the top line. The chain of frames is what lets it walk from where the error surfaced back to where it originated.
Step 2: Ask Claude to trace it to a cause
Ask for the originating line and the condition that makes the value undefined. Asking for the why, not just the where, surfaces the real defect instead of the throw site.
Step 3: Choose a fix that matches the data
Decide whether the right fix is to handle the missing profile, to filter those rows, or to make the join required. Pick based on what the data should look like, then have Claude apply it.
- return { id: row.id, profileId: row.profile.id };
+ return { id: row.id, profileId: row.profile?.id ?? null };Step 4: Add a regression test
Lock the fix with a test that feeds in a row without a profile and asserts it no longer throws. This stops the same crash from coming back later.
it("handles a user with no profile", () => {
expect(() => toDTO({ id: 7, profile: undefined })).not.toThrow();
expect(toDTO({ id: 7, profile: undefined }).profileId).toBeNull();
});Result: the crash is traced to users without a profile, fixed with safe access at the serializer, and guarded by a regression test that reproduces the original input.
Watch related tutorials
1:42:18
28:14
41:09
9:47
8:23
52:31