Section 1.6: Errors and Debugging

Code fails, and the failure is information. A syntax error means the file never ran at all, a runtime error means it ran and hit something impossible, and a logic error means it ran to completion and gave you a wrong answer with no complaint whatsoever. Those three demand completely different responses, and telling them apart starts with when the failure appears and what it prints, then reading the traceback properly rather than scrolling to the bottom and guessing. This section covers that reading, the mechanism for catching failures you anticipated, and the systematic process for locating the ones you did not.

Section 5 pointed your code at real files, which is exactly the moment failure stops being hypothetical. A file that is not there, a row with the wrong number of fields, a number stored as an empty string, an encoding that is not what you assumed. A parser written against clean input crashes on the first malformed row and takes the other forty thousand good rows with it.

Lessons

  1. The Three Kinds of Error and How to Read a Traceback - telling syntax, runtime and logic errors apart, and reading a traceback from the correct end.
  2. Handling Exceptions - try, except, finally, raise - catching what you expect, cleaning up regardless, and signaling failure deliberately.
  3. Defensive Code and Systematic Debugging - validating input at the boundary, and locating a bug by narrowing rather than by staring.

By the end you will be able to:

  • Classify a failure as syntax, runtime or logic from its symptoms alone.
  • Name the line and the cause of a failure by reading its traceback.
  • Catch a specific exception type without swallowing the types you did not anticipate.
  • Locate a logic error by narrowing the input systematically rather than by staring at the code.