Module 4 · Exceptions · Lesson 5 of 6

Finding and fixing bugs

Exceptions handle bad data. The other half of the battle is bad code — the bugs you write yourself. You can't avoid making them, so the real skill is finding them. And finding them starts with one habit: test every path your code can take.

An if/elif/else has several routes, and a test only checks the route it actually triggers. Here's the sting: because Python is interpreted, it doesn't pre-scan lines it never runs — so a glaring typo on an untested branch sits there silently until someone finally takes that path.

That's why describe(5) and describe(-2) look perfect, while describe(0) blows up on a typo Python never warned you about. A good test set has to reach every branch — here, a positive, a negative, and a zero.

When something is wrong, the oldest trick in the book still works: print debugging. Sprinkle a few print() calls to show which path ran and what your variables actually hold — then remove them once you've found the culprit.

A few more habits that pay off: explain the problem out loud to a colleague — or a rubber duck (yes, really) — and the act of narrating often surfaces the bug. Isolate the suspect code and run it alone. If it broke recently, review what you just changed. And take a break — answers arrive on walks more often than at the keyboard.