Debugging JavaScript on iPhone: using a console

Why you need a console on iPhone

When JavaScript hits an error, it stops running that piece of code – and the page simply looks frozen. The console is where that error is reported, including the line where it happened. Without a console you only see the symptom, never the cause.

Code Editor has a console built in: console.log output, warnings and errors with their line number appear right below the live preview, and tapping an error jumps to its line.

console.log, console.warn and console.error

These three methods cover most debugging. They all accept several values separated by commas, so you can label what you print.

const items = ["apple", "pear"];

console.log("Items:", items);
console.warn("Only", items.length, "items");
console.error("Could not load prices");

• console.log – everyday output: values, checkpoints, “got here” messages
• console.warn – something unexpected that isn't fatal, such as an empty list
• console.error – something went wrong, for example a failed request

A simple debugging routine

Most bugs can be found by checking your assumptions one at a time. Log the value right before the line that misbehaves and compare it with what you expected.

Here is a classic: a total that comes out as text instead of a number. Logging the result shows "053" instead of 8, because one price is the string "5" and the + operator joins strings instead of adding them. Converting with Number(price) fixes it.

function total(prices) {
  let sum = 0;
  for (const price of prices) {
    sum += price;
  }
  return sum;
}

console.log(total(["5", 3])); // "053" instead of 8

Common error messages on iPhone and iPad

Safari and other browsers on iPhone and iPad use Apple's JavaScript engine, and its messages read differently from the ones in Chrome tutorials. Here are the ones you'll meet most often, with what they usually mean.

How to read an error message

An error message has three useful parts. The type (ReferenceError, TypeError, SyntaxError) tells you the category. The text explains what went wrong, often quoting the exact expression in parentheses. And the line number tells you where to look.

Be aware that the line with the error isn't always the line with the mistake. If button is null on line 12, the real problem may be a wrong id in your HTML or a script tag placed in the head before the body exists. Start at the reported line, then trace the value backwards to where it came from.

• SyntaxError: the code couldn't even be read – check brackets, quotes and commas near the line.
• ReferenceError: a name doesn't exist – check spelling and where it's declared.
• TypeError: a value has the wrong type – log the value right before the line.

Try things out in the console prompt

Sometimes you just want to know what an expression returns – what does "5" + 3 give, or how does an array method behave? In Code Editor you can type JavaScript into the console prompt and see the result immediately, with a history like a terminal. That is often faster than editing the file and reloading.

Clean up before you publish

Debug output is meant for you. Before you publish, remove console.log lines that print internal values, keep console.error for real failures and make sure the console is free of errors when you use the page as a visitor would.