Errors are the language a program speaks
A beginner sees red text and panics. A professional reads it: an error message contains what happened, where, and why — the most informative text a program can produce. The difference between a beginner and a pro is not the number of errors, but the speed of reading them.
Anatomy of a message
Run it — the program will crash:
Read it bottom to top (in Python) or top to bottom (in JS):
- Error type:
TypeError/KeyError— the category of the problem. - Message:
Cannot read properties of undefined/'comment'— the specifics: you reached for something that doesn't exist. - Line: the line number where the program tripped.
Notice: "Started" printed — the error stopped the program at the moment of the crash, everything before it ran. That's a hint in itself: the problem is between the last successful output and the end.
Three common error types
- Syntax — the program didn't even start running: a forgotten bracket, quote, colon. Fixed by looking at the indicated line (and often the line above — the bracket was forgotten there).
- Runtime — the program was running and crashed: accessing a nonexistent field, dividing by a string, reading a missing file.
- Logic — the worst: the program runs without errors, but the result is wrong. No messages — only your check of the result.
Debugging with output
The main tool for finding problems is old as the hills — printing intermediate values:
The method: sprinkle console.log/print before, inside, and after the suspicious spot, and watch where the values diverge from expectations. Found it — fix it, remove the debug lines.
Handling expected errors
Some errors are a normal part of life: broken JSON, an unreachable site, a missing file. The program shouldn't die from them — it should handle them:
try/catch (JS) and try/except (Python): try the risky thing, on error run a fallback plan instead of crashing. In the monitoring case study from the AI course this looked like "network errors — three retries with a pause" — now you know what it's made of.
AI as a debugger
The modern workflow: copy the error message together with the chunk of code into Claude — the diagnosis and fix are almost always instant. But you didn't take the lesson for nothing: understanding the anatomy of an error, you verify the AI's diagnosis instead of blindly applying it. AI also finds logic errors without messages worse — there you need your DEBUG output and your understanding of the expected result.
Key takeaways
- An error message = type + specifics + line; read it, don't fear it.
- Three types: syntax (didn't start), runtime (crashed), logic (runs wrong — the worst).
- Debugging with output: print intermediate values, look for the divergence from expectation.
try/catch/try/except— expected errors are handled, not left to crash the program.