Pythonoid

CurriculumThe Dragon's Diagnosis

Reading Python Error Messages, for Kids

A Python error message already tells you what went wrong — this topic teaches how to actually read it.

12 exercises4 lessonsAges 10+PRO
See what PRO unlocks →

What this topic covers

Most beginner materials either hide error messages behind a friendlier paraphrase or leave children to decode a raw traceback with no guidance at all. The research on this specifically finds that rewriting error text has little effect on its own, while teaching a systematic procedure for using it does — a documented, replicated result. So this topic keeps the real Python traceback exactly as it appears, and teaches the habit of reading it: the last line first, where it names the exact problem, then the line number, which points at where the program broke rather than always at the original mistake.

The middle of the topic builds recognition of the exception types a learner meets most often — IndexError, KeyError, TypeError, ValueError, ZeroDivisionError — as fast pattern-matches rather than mysteries to re-derive from scratch each time, alongside the harder distinction between an error Python catches immediately (a broken syntax), one it catches while running (a real crash), and one it never catches at all: code that runs perfectly and produces a wrong answer, silently, with no traceback to point at anything.

That last category is where the topic's final procedure earns its place — read what happened (or notice nothing did), say what you expected, change one thing, run again. The one-thing-at-a-time step is deliberate: research on this finding also reports it is the step children skip under pressure, changing several things at once and losing the ability to tell which change actually mattered.

Python from this topic

hoard = ["gold", "gems"]
print(hoard[5])

Output

IndexError: list index out of range

Python covered here

  • Reading a traceback's last line first
  • Recognising IndexError, KeyError, TypeError, ValueError, ZeroDivisionError by name
  • Syntax errors vs. runtime errors vs. logic errors
  • Why a logic error produces no error message at all
  • A five-step debugging procedure: read, expect, observe, change one thing, rerun

The mistake this topic is built to fix

Common mistakeA child treats every crash as an unreadable wall of red text, or assumes a program with no error message must be correct.

Novice debugging strategies are documented as unsystematic, and error messages themselves are a barrier when there is no method for using them. The gap is not information — Python already supplies it — it is a missing procedure for reading and acting on it, which this topic teaches directly rather than assuming it develops on its own.

The lessons, in order

  1. Reading a traceback bottom-upThe last line of a crash names the real problem — read it first, not last.3 exercises
  2. Name that exceptionRecognise the common crash types by name, the way a symptom points to a diagnosis.3 exercises
  3. Syntax, runtime, and logic errorsThree completely different kinds of wrong — and the hardest one leaves no error message at all.3 exercises
  4. The Debugging ProcedureRead it, say what you expected, change ONE thing, run again — the loop that actually works.3 exercises

Lessons unlock in order within a topic, so nothing arrives before the idea it depends on. This topic is part of PRO — $6.99 unlocks it along with everything else.

Try it now

The very first level needs no account at all — see whether it clicks before signing up for anything.

Play the first level free →