When a Python script crashes, I still have the bad habit of reading only the final exception line. Yesterday it said `KeyError: 'email'`, so I added a default value, but the real problem was an earlier function passing the wrong dictionary into the formatter. Following the call frames upward made that obvious. Does anyone have a good repeatable method for reading tracebacks—where to start, what to ignore, and how to identify the first line that's actually mine?
Getting comfortable reading stack traces instead of copying the last error line
- programming-help
- comfortable
- reading
- stack
60
1 reply
I like to look for the first unexpected variable value, not just the final exception. If one function passes a list where the next one expec...
I like to look for the first unexpected variable value, not just the final exception. If one function passes a list where the next one expects a dict, the traceback is basically a breadcrumb trail for that mismatch.
That part helps, but I still get lost when the traceback is long. Do you ignore the repeated frames from the same helper function, or do those usually matter?
2 replies
Start at the bottom, then move up until you reach your code. The last line tells you what failed, but the useful part is usually the first f...
Start at the bottom, then move up until you reach your code. The last line tells you what failed, but the useful part is usually the first frame where the traceback points into your file rather than into library code.
So if the stack has a bunch of library frames first, I should skip those until I hit my own file? I always hesitate because I’m not sure where the actual mistake starts.
Pretty much. The library frames matter for context, but your best clue is usually the first place the call passes through your code and the...