Finding and fixing what's wrong: debugging
Up through inheritance you built a fairly large program (lesson 13). But a program you build always goes wrong somewhere. One typo, one mistaken assumption is enough. Going wrong isn't failure; it's an everyday thing. Calmly finding and fixing it is debugging.
It points at where it stopped
When a program goes wrong,
it doesn't die quietly; it stops at one spot.
And it points a finger: 'here, this line.'
That pointing is the most valuable first clue.
An error first tells you 'where' it stopped.
Press run. The steps light up in turn, then stop right at the wrong spot.
You can see at a glance where it stopped.
Now some red text will appear at that spot.
Many people get scared the moment they see it.
But it's actually on our side. Because...
Red text is a hint, not a scolding
That red text isn't telling you off.
It's a note saying 'what it couldn't understand'.
Usually it holds two things: the spot (where) and the kind (what).
Like 'this isn't a number', 'there's no such name'.
Learn to read it calmly and you're halfway there.
Tap the message parts. The 'where' and the 'what' light up separately.
Read the message as 'where' and 'what',
and the scary text suddenly looks friendly.
But the spot it points to isn't always the real cause.
In a long program, how do we narrow the cause fast?
Narrow the range by halving
When you don't know where the bug is,
don't read it all; look at the middle.
Is it fine up to here? Then the bug is in the back half.
If not, it's in the front half. Halve again.
This 'halving' finds the culprit fast, even in long code.
Press 'check the middle'. The range halves based on fine or broken.
A few presses and the range narrowed to one spot, right?
We pinned the culprit without reading everything.
Now that we've found the cause, it's time to fix.
But there's one trap when fixing.
Change one thing at a time and check
Don't touch everything at once just because you spot a likely cause.
If you change five places at the same time,
even if it works, you can't tell which fix did it.
And if a new problem appears, you can't tell whose fault it is.
So change one thing, run it, and observe.
Flip just one guess and 'check'. Flip many and what fixed it blurs.
Changing one at a time makes the real cause clear.
We know the culprit exactly, and we fixed it.
So are we done? One step still remains.
Because 'seems fixed' and 'is fixed' are different.
After fixing, always re-run and confirm
Just thinking you fixed it isn't the end.
It's done only when you re-run and watch it pass to the end with your own eyes.
As a bonus, check that nothing else that was fine got broken.
This one loop of 'fix and re-confirm'
is the line between guessing and really fixing.
Press 're-run'. The fixed program passes green to the very end.
Now we know how to build (lessons 1-13),
and how to find and fix when it breaks (lesson 14).
But these letters we wrote,
how do they become something a real machine runs?
Next, we'll follow the path from our text to the machine's work.