Phase 5: Debugging Methodology · ~35 minutes · Python · tracebacks

Reading a Stack Trace

A traceback fifteen frames long still has exactly one line that names the actual error. It's at the bottom, and it's the only line you need to find first.

Hiring signal: Never panics at a long traceback — reads the bottom line first, then works upward only as needed

What you will learn

Read stack frames in true execution order, correcting the common 'read it backwards' confusion
Find the actual error type and message without being overwhelmed by a long traceback
Identify which frames are your own code versus library/stdlib code
Diagnose five real, distinct tracebacks confidently

Introduction

Type: Learn Languages: Python Prerequisites: Lesson 01 (The Cheapest Tool First) Time: ~35 minutes

Objective

Learning objectives

Read stack frames in true execution order, correcting the common "read it backwards" confusion
Find the actual error type and message without being overwhelmed by a long traceback
Identify which frames are your own code versus library/stdlib code
Diagnose five real, distinct tracebacks confidently

What you're building

Given 5 real, unfamiliar tracebacks (your own instructor may provide these, or construct your own 5 following this lesson's variety — one library-heavy, one shallow, one custom exception, one with a boundary/nested-access failure, one of your own invention):

For each, identify the exact error type and message (the bottom line)
For each, identify the specific line where the error actually occurred (the frame immediately above the error)
For each, classify every frame as "your code" or "library code"
Write trace_diagnosis.txt with your findings for all 5, plus one sentence per trace on where the actual fix belongs

A traceback has 8 frames. Frames 1-3 are your own application code. Frames 4-8 are deep inside a database library. The final line reads ValueError: invalid literal for int() with base 10: 'N/A'. Where does the fix most likely belong?

This is exactly this lesson's requests.exceptions.ConnectionError pattern, generalized: a library correctly reports being handed something it can't work with — here, being asked to convert the literal string 'N/A' to an integer, which is genuinely not possible. The library isn't misbehaving; it's accurately reporting a real problem with its input. The fix belongs in your own outermost frame (frame 3, right where your code called into the library), most likely by validating or converting 'N/A' into a real number or a sensible default before it's ever passed into the library at all.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.