Errors Are Evidence

Unit ID: M06-U00 Estimated active time: 18-25 minutes

Failure is information

When code fails, the goal is not to make the red message disappear at any cost. The goal is to explain what happened and correct the cause.

Three broad categories help.

Syntax errors

Python cannot parse the code:

if hours >= 0
    print(hours)

The missing colon causes SyntaxError. The program cannot begin normal execution.

Runtime errors

The syntax is valid, but execution reaches an invalid operation:

hours = "eight"
print(int(hours))

This raises ValueError because the text is not a valid integer representation.

Logic errors

The program runs but produces the wrong result:

hours = [8, 12, 4]
average = sum(hours) / 2
print(average)

No exception occurs, but the divisor is wrong. A test or independent expected result must reveal the defect.

Do not classify too early

An incorrect output may come from stale notebook state, wrong data, wrong logic, or a misunderstood requirement. Record the evidence before naming the cause.

A debugging record

For each failure, write:

• expected behaviour;
• actual behaviour;
• smallest input that reproduces it;
• exception type and message, if any;
• relevant line and call path;
• suspected cause;
• one change made; and
• test result after the change.

Practice

Classify these:

1. Missing closing quotation mark.
2. Dictionary key does not exist during execution.
3. Total hours is doubled because a notebook cell ran twice without resetting state.
4. Code divides by the wrong record count but finishes.

The first is syntax; the second runtime; the third and fourth are logic or state defects.

Takeaway

Errors and wrong outputs are evidence. Describe expected and actual behaviour before editing. Next, we will read a traceback as a path through function calls.