Every program you’ll ever write will break. The difference between a beginner and a programmer is knowing which kind of broken you’re looking at.
The book’s error taxonomy. It maps onto the three types below. Enrolled in our Runestone course? Open it from there so your progress counts.
Still in Programs. In 2.1 you met errors and were told not to panic. Today you get the vocabulary that makes that promise real — three named categories, and a different fix for each.
Name the category and the fix becomes obvious. The exam knows this — “what type of error is this?” is one of the most reliable easy questions on the whole test. Today is about collecting those free points and never flailing again.
Three kinds of error, told apart by when they bite:
| Type | When | Tell |
|---|---|---|
| Syntax | before it runs | Broke a grammar rule — missing quote, paren, or colon. Won’t start at all. |
| Run-time | while running | Legal code hits something impossible — divide by zero, convert “hello” to int. Crashes partway. |
| Logic | never crashes | Runs fine, gives the wrong answer. No error message — the sneakiest kind. |
When a run-time error hits, Python prints a traceback — a few lines of red that look scary and are actually a map. Read it bottom-up: the last line names the error type and message; the line above points at where. That’s usually all you need.
Traceback (most recent call last): File "greet.py", line 3, in <module> age = int("twelve") ValueError: invalid literal for int() with base 10: 'twelve'
Bottom line: a ValueError. The line above: it happened converting
"twelve". Now you know it’s a run-time error and exactly where. That’s the
whole skill.
Four broken programs. For each, decide: does it break before running (syntax), during (run-time), or not at all but give a wrong answer (logic)? Pick, then see the verdict.
Five questions in AP format. Pick an answer for instant feedback.
Syntax and run-time errors are loud — they stop the program and point at themselves. Logic errors are silent, and that makes them the dangerous ones. A program that computes the wrong dosage, the wrong tax, or the wrong grade runs perfectly. Nothing turns red. The only way to catch it is to test with inputs where you already know the right answer, and check that the program agrees.
This is why professionals write tests before trusting code, and why “it ran without errors” is not the same as “it’s correct.” You’ll build this instinct at the end of the unit (2.16, edge cases) — but it starts here, with the realization that the scariest bug is the one that never crashes.
int("hello") crash is a run-time error, and
now you can name it.