Teach & case

Help a near-peer reason through the idea — when you explain it, you understand it best — then read the real decision it comes from.

A real case · you decide

Lin's crash on line 42

Lin — a student whose program crashes with an error pointing at line 42

The idea in play: tracing state line-by-line to find a bug — not guessing from where the error surfaced.

Lin's program crashes: "TypeError on line 42 — cannot read length of undefined." Line 42 looks fine. Her instinct is to start rewriting line 42 until the red goes away.

The crash SURFACED on line 42, but that's where the bad value was USED — not where it was created. The variable became undefined somewhere earlier and rode along until line 42 tried to use it.

Lin adds a print (or a breakpoint) at each step and watches the variable's actual value change line by line. On line 27 it's a list; on line 31 a function returned nothing and overwrote it with undefined. THAT's the bug — 15 lines above the crash.

The error points at line 42. Where's the actual bug most likely to be?

Lin's friend says "just add a try/catch around line 42 so it stops crashing." Good fix?

Lin fixes line 31, and line 42 never complains again. That's Lin's whole method: follow the state to where it first goes wrong, instead of arguing with the line that happened to crash.

Trace a bug yourself in the Debugger →