JS Sketchbooksee JavaScript think ✏️
← back to phase 0

0.5 — Errors are messages, not failures

Very soon you’ll write real code — and sometimes the machine will answer in red. Most beginners see red text and feel they failed. Let’s permanently install the opposite reflex: an error is the machine asking you for help — and it always tells you what went wrong and where.

Learning to read errors calmly is a superpower — and for a future tester it’s doubly true: provoking errors and reading them carefully is literally part of the job.

watch it happen
console.log("Starting…");
console.lgo("Hello!");
console.log("Done");

Three instructions — but look closely at line 2. There’s a typo: lgo instead of log. We’ll run it anyway, on purpose, and watch what the machine does.

the console
under the hood

The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”

Meet the big three error categories — between them they cover most of what you’ll see for months. SyntaxError: “I couldn’t even read this” — the grammar is broken (a missing quote or bracket), so the program doesn’t start at all.

ReferenceError: “you used a name that doesn’t exist anywhere” — like consoel.log(…) or using a variable you never created.

TypeError: “that thing exists, but it can’t do what you asked” — like our console.lgo (console exists; lgo isn’t something inside it you can call).

Real errors usually come with extra lines underneath, called a stack trace — a list of “who called whom” leading to the failure. It looks scary. It is actually a trail of clues. It becomes genuinely useful once you know functions (Phase 3), and we will read them together then. Until that day: the first line is the letter, the rest is the envelope.

A professional habit to start now: when several errors appear, read the first one — the later ones are often just fallout.

And keep this framing forever: errors are evidence, not verdicts. 💼 On the job — your work includes making software fail on purpose and reading what it says. A tester who reads error messages calmly and precisely is rare and valuable.

your turn

✏️ Quick check 1

The console says: “ReferenceError: userName is not defined.” What is the machine telling you?

✏️ Quick check 2

An error appeared at line 12. Lines 1–11 already ___ — type the one word (ran / waited / cancelled).

✏️ Quick check 3

Red text fills the console — several errors at once. Which one do you read first? Type "first" or "last".

teach it back

🗣️ Now teach it back

Your friend just got their first error and wants to give up. Explain: what IS an error really, what are the three parts to read in one, and what should they do next?

Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.

a few sentences, minimum — you’ve got this
to remember
An error = the machine asking for help: a category, a message, and the exact line. Read it like a letter, not an alarm.
Errors stop the program AT the failure point: everything before ran, everything after never did.
The big three: SyntaxError (couldn’t read it), ReferenceError (name doesn’t exist), TypeError (thing can’t do that). Read the FIRST error first.
next: 1.1 What is a value? →