Debugging and Reading Errors — Turning Red Text into Clues

1.An error message is a clue

When you start writing code, red errors appear often. The same goes for professional developers. The difference is whether you panic when you see an error or read it as a clue. Finding and fixing errors is called debugging, and the first step is to read the message all the way to the end, word by word. The message usually contains the very name of the thing you need to fix.

A JavaScript error message has the shape ErrorName: description. For example, TypeError: Cannot read properties of undefined (reading 'length') means 'the kind is TypeError (the kind of value is wrong), and what happened is that we tried to read length from undefined'. For errors that happen while the code is running, this playground also shows which line the error happened on. That line is your starting point.

Two things are worth knowing. First, the description wording differs slightly between browsers. The messages in this lesson are the wording of V8, the engine used by Chrome-based browsers; other browsers may describe the same error in different words. The error name (TypeError and so on) is fixed by the language rules, so it is mostly the same in every browser. Second, the line where the error happened may not be the line with the mistake. It is common for a value to be made wrongly higher up and to blow up further down, where it is used.

When an error happens, execution stops at that line. So a console.log before the error is printed and one after it is not. This behaviour is a clue that tells you 'how far things ran correctly'. The code below prints the first line and then stops at line 3.

const words = ["apple", "pear"];
console.log(words[0].length);
console.log(words[2].length);
console.log("This line never runs");

5
TypeError: Cannot read properties of undefined (reading 'length')

• Error name — what kind of problem is it (SyntaxError, ReferenceError, TypeError, RangeError …)
• Description — what was being done when it got stuck (which name, which property)
• Line number — where it stopped (the mistake may be above it)

2.`SyntaxError` — code that doesn't run at all

A SyntaxError is a grammar error. It happens when the code can't be read as JavaScript — for example when you didn't close a bracket, left out a comma or declared the same name twice. Unlike other errors, it is caught at the reading stage, before the code runs, so not a single line is executed. If even a console.log at the very top prints nothing, suspect a syntax error first.

For syntax errors, this playground shows only the message, without a line number. That makes the clues in the message even more important. missing ) after argument list means the closing bracket of a function call is missing, and Unexpected identifier 'price' means 'price appeared where it shouldn't', in other words something like a comma is missing just before it. When you see Unexpected token, look at the part right before that character. If a name is shown in quotes, searching for that name is a fast way to find the spot.

Syntax errors usually come from things that don't pair up. Check that every opening bracket, curly brace and quote has its closing partner; lining up the indentation makes a broken pair stand out. An editor that highlights matching brackets also helps a lot. Instead of writing long code in one go, write and run a few lines at a time — then when a syntax error appears, you only need to look at the few lines you just wrote.

console.log("hello";

SyntaxError: missing ) after argument list

const item = {
  name: "apple"
  price: 1500
};

SyntaxError: Unexpected identifier 'price'

let count = 0;
let count = 1;

SyntaxError: Identifier 'count' has already been declared

3.`ReferenceError` — no such name

A ReferenceError means 'that name can't be found'. The most common cause is a typo. If you write console as Console or total as totla, JavaScript tells you there is no variable with that name. Upper- and lowercase count as different names. Copy the name that appears before is not defined in the message and search for it in your code, and the place where the spelling differs soon shows up.

The second cause is 'using it before declaring it'. Using a variable made with let or const above the line where it is declared gives Cannot access 'price' before initialization. The third is scope. As we saw in Lesson 5, a variable made inside a function or a { } block can't be seen outside it. Trying to use a variable made inside a loop after the loop has finished gives is not defined.

In code running in strict mode, as in this playground, assigning a value to a name you have never declared, without let or const, is also a ReferenceError. Outside strict mode, this mistake silently creates a new global variable and turns into a bug that is even harder to find; strict mode reports it as an error straight away.

const total = 100;
console.log(totla);

ReferenceError: totla is not defined

console.log(price);
const price = 1500;

ReferenceError: Cannot access 'price' before initialization

for (let i = 0; i < 3; i++) {
  const last = i;
}
console.log(last);

ReferenceError: last is not defined

4.`TypeError` — something that value can't do

A TypeError means you asked a value to do something that doesn't fit its kind, and it is the error beginners meet most. The classic one is Cannot read properties of undefined (reading '…'). undefined and null have no properties, yet you put a dot (.) after one to take something out. The name in the brackets is the property you tried to read, and the value just to the left of that dot was undefined.

What matters is 'why did that value become undefined?'. When you read an array slot that doesn't exist (arr[5]) or a property that doesn't exist (user.nmae), JavaScript doesn't throw an error; it quietly returns undefined. The error only comes the moment that undefined is used once more. So print the value to the left of the dot on the error line with console.log, and trace upward to where it came from. The culprit is usually an index out of range, a typo in a property name, or a function that forgot return and so returned undefined.

Another one you will see often is … is not a function. It means you called something that isn't a function with brackets () — either a typo in a method name (toUppercase) or calling a method on the wrong kind of value. For example, toFixed is a number method, so calling it on the string "1500" gives this error. This ties back to the type conversion problems from Lesson 2. Assigning a new value to a variable made with const, which gives Assignment to constant variable., is also a TypeError.

const user = { name: "Alex" };
console.log(user.nmae);
console.log(user.nmae.length);

undefined
TypeError: Cannot read properties of undefined (reading 'length')

const s = "hello";
console.log(s.toUppercase());

TypeError: s.toUppercase is not a function

const price = "1500";
console.log(typeof price);
console.log(price.toFixed(0));

string
TypeError: price.toFixed is not a function

5.`RangeError`, and bugs that give no error

A RangeError means the kind of value is right but it is out of range. You get one by giving a negative count, as in "*".repeat(-1), or a negative length, as in new Array(-1). When a function calls itself endlessly you get Maximum call stack size exceeded, which in Chrome-based browsers (V8) is also a RangeError (Firefox reports the same situation as InternalError: too much recursion). Recursion, where a function calls itself, must always have a condition that makes it stop.

Trickier are bugs that produce no error at all: the code runs to the end but the result is wrong. The off-by-one from Lesson 4 is the classic case. Looping with i <= arr.length reads a slot that doesn't exist at the end and adds undefined, and adding undefined to a number gives NaN instead of an error. Dividing by 0 gives Infinity, and 0 / 0 gives NaN — again, no error. If you see NaN, undefined or Infinity in a result, it is a bug signal even without an error message.

A loop that never ends doesn't give an error message either. If the condition of a while is true forever, the program just keeps running. This playground force-stops code that doesn't finish within 2 seconds and tells you it hit the time limit. When you see that notice, suspect the loop's end condition. Check whether the variable used in the condition actually changes inside the loop, and whether it changes in the direction that brings it closer to the end. Running an infinite loop in a real browser tab can freeze the tab, so when you first write a loop, test it with small inputs.

function stars(n) {
  return "*".repeat(n);
}
console.log(stars(3));
console.log(stars(-1));

***
RangeError: Invalid count value: -1

const nums = [10, 20, 30];
let sum = 0;
for (let i = 0; i <= nums.length; i++) {
  sum += nums[i];
}
console.log(sum);
console.log(10 / 0, 0 / 0);

NaN
Infinity NaN

6.The order of debugging — print, hypothesise, shrink

Debugging has a set order. First, write down 'the result I expected' and 'the result I got' in one sentence each. Next, form one hypothesis about the cause (for example: the loop runs one time too many) and run the smallest experiment that can check it. If the hypothesis is right, fix it; if it is wrong, cross it out and move on to the next one. If you change several places at once, you can't tell which change fixed it, so change only one thing at a time.

The handiest experiment tool is console.log. Printing the value at a suspicious spot shows where 'the value in my head' and 'the actual value' start to part ways. Inside a loop, print the index together with the value, and add a label next to the value (console.log("i:", i)) so you don't get confused when the output gets mixed. Printing typeof as well lets you tell apart values that look the same, like "1500" (a string) and 1500 (a number). Once you've found the problem, remove the checking output.

When the code is long, build a minimal reproduction. While keeping the bug appearing, delete unrelated lines one by one until only the shortest code that causes the problem is left. The cause often becomes visible while you shrink it, and when you ask someone else or an AI, short code gets a much more accurate answer. Since explaining often reveals the answer, explaining your code out loud, line by line, is also a widely used method (rubber duck debugging).

const sales = [10, 20, 30];
let sum = 0;
for (let i = 0; i <= sales.length; i++) {
  console.log("i:", i, "value:", sales[i]);
  sum += sales[i];
}
console.log(sum / sales.length);

i: 0 value: 10
i: 1 value: 20
i: 2 value: 30
i: 3 value: undefined
NaN

7.What to give an AI when you ask about an error

An AI coding assistant is quite useful for explaining error messages and suggesting a direction for the fix. But it is only as accurate as the information it gets. Rather than 'it doesn't work, fix it', give it the full error message, the minimal code that shows the problem, the expected and actual results, the environment (browser, engine) and what you've already tried, and the answer will be far more accurate. Don't summarise the error message — copy and paste it exactly. Translating or shortening it loses key clues (names, properties, line numbers).

There are also things you must strip out before pasting. Passwords, API keys, access tokens and personal information such as real customers' names and phone numbers must be removed and replaced with fake values, even if they are mixed into the code or data. If it is code from your company or school, first check their policy on whether you may paste it into an outside AI. Lesson 10 covers this in more detail.

When you get code fixed by an AI, don't trust it as is — check it. Run it yourself and see whether the original error is gone, whether you get the expected result, and whether it is still right for edge cases like an empty array or 0. AI sometimes gives explanations that sound plausible but are wrong, and sometimes 'fixes' things in a way that only hides the error (for example, always turning the problem value into 0). Ask it to explain why it made the change, and check whether that explanation fits the error message.

• The full error message (name, description, line number) — copied exactly
• The shortest code that shows the problem (minimal reproduction)
• The expected result and the actual result
• The environment (which browser, whether it is this playground, etc.) and what you've already tried
• Passwords, keys and real personal information removed and replaced with fake values