flowchart LR reproduce["Reproduce"] --> observe["Observe evidence"] observe --> localize["Localize the failure"] localize --> hypothesize["State one hypothesis"] hypothesize --> change["Change one thing"] change --> rerun["Rerun the same case"] rerun --> regression["Run regression checks"] regression -->|still wrong| observe regression -->|stable| done["Record the repair"]
FreeCampus Python
Errors, Exceptions, and Debugging Overview
Classify failures, read tracebacks, handle expected exceptions, and repair bugs through small evidence-backed experiments.
python-foundations
errors-exceptions-debugging
overview
Course progress
0%
1. Welcome to the arcade repair desk
An arcade machine can fail in at least three noticeably different ways:
- its game script may not start because Python cannot understand the code;
- it may start and then stop when a player enters an unexpected command; or
- it may finish without an error while moving the character in the wrong direction.
Those are not variations of one problem. They leave different evidence and call for different first moves. This unit teaches you to treat a failure as an investigation rather than a guessing contest.
By the end, red tracebacks should feel like structured reports. A silent wrong answer should prompt you to write down the expected result and find the first place where state diverges. An anticipated bad input should lead to one narrow, useful exception boundary—not a blanket try block that hides every defect.
2. Follow the evidence loop
The investigation repeats until the repaired behavior survives both the original case and nearby regression checks.
This loop is intentionally slower than random editing for the first few minutes. It is usually much faster over the whole investigation.
An evidence log makes the loop visible:
| Reproduction | Observed evidence | Hypothesis | One change | Verification |
|---|---|---|---|---|
move_pixel((0, 0), ("LEFT", 1)) |
returns (1, 0) |
the left branch adds instead of subtracts | change that branch only | original case and four direction checks pass |
“The function is broken” is not a useful hypothesis. “The LEFT branch uses the same update as RIGHT” is specific, testable, and can be disproved.
3. Your route through the unit
| Step | Lesson | What you will be able to do |
|---|---|---|
| 1 | Understand Failures and Read Tracebacks | Tell syntax failures, runtime exceptions, and wrong results apart; extract evidence from tracebacks and common exception types. |
| 2 | Raise Useful Errors and Handle Expected Failures | Design narrow exception boundaries, add context without erasing causes, and allow unexpected defects to remain visible. |
| 3 | Debug One Hypothesis at a Time | Reproduce a wrong result, localize its first divergence, run controlled experiments, and verify a root-cause repair. |
| 4 | Pause, Inspect, and Shrink a Bug | Choose between prints, assertions, a debugger, and a minimal reproduction; inspect program state without changing it accidentally. |
| 5 | Unit Challenge: Repair the Glitched Arcade | Repair a command-driven game while preserving useful failures and proving the final behavior with assertions. |
The first two lessons concentrate on failures Python reports. The next two concentrate on investigations you must lead. The challenge combines both.
4. Bring forward the habits from Unit 7
Unit 7 separated a problem statement from its examples, acceptance rules, and algorithm. Keep that separation here. A logic bug is visible only when you have an oracle: a rule, example, assertion, or independently calculated result that says what should have happened.
Before editing code, write these four lines:
If one line is unknown, investigate that missing evidence first. Changing code before you know the expected behavior can produce a different program without producing a correct one.
Unit 9 will add files, paths, and external data. This unit deliberately uses small in-memory values so that an input format or operating-system path cannot distract from the failure itself.
5. Set up two useful practice environments
Use the generated notebook for quick experiments, traceback reading, and assertions. Run cells from top to bottom when confirming a repair; old notebook state can make deleted code or stale variables appear to work.
For the debugger lesson, also save a complete example as a local .py file. You can run it normally before introducing the debugger:
Then run the same file under Python’s debugger:
The goal is not to memorize a particular editor. It is to understand pauses, frames, variables, stepping, and continuation well enough to recognize them in Python’s pdb, VS Code, or another debugger.
WarningDo not debug a secret in public evidence
Tracebacks, debugger displays, screenshots, and minimal reproductions can expose passwords, tokens, personal records, and local paths. Replace sensitive values with harmless examples while preserving the data shape that triggers the bug.
6. Budget time for investigation, not only reading
A realistic pace is four to five hours per main lesson and one to two hours for the challenge. That includes typing examples, predicting results, deliberately triggering failures, completing labs, and recording one investigation.
For every repair clinic:
- reproduce the exact failure without editing;
- name the category and copy the decisive evidence;
- shrink the input or inspect the suspicious state;
- state one hypothesis that could be false;
- make one controlled change;
- rerun the original reproduction;
- add a regression check that would fail if the bug returned.
TipKeep one useful failure
Do not erase every failed attempt from your notes. Preserve one failure, the hypothesis it challenged, and the evidence that changed your mind. That record shows more debugging skill than a final green check by itself.
7. The challenge ahead
Pixel, an arcade character, must follow movement commands and reach a portal. The supplied program looks plausible but mishandles invalid commands, one direction, and an exception boundary. Progressive assertions will let you repair one subsystem at a time without needing a teacher to reveal the answer.
Your final evidence will include:
- a parser that rejects malformed commands with useful context;
- movement rules that work in all four directions;
- a game loop that continues after anticipated command mistakes without hiding unexpected programming defects;
- assertions run from a clean state; and
- a short evidence log for one repaired defect.
There is no final project or certificate in this release. Both are planned, and we will announce them when they are ready. For now, the strongest proof of progress is a program you can explain, break deliberately, repair, and rerun.