9.3 Error Handling and Debugging

Learning Objectives

By the end of this section, you will be able to:

9.3.1 What You Already Know

Section 2.5 built the try...catch construct from the ground up, and none of it has changed. This is the whole of it, in one program:

▶ Press Run to see the output…

What you should see:

Attempting the risky work.
Caught a ReferenceError
It said: missingValue is not defined
finally runs either way.
And the program carries on.

Four pieces, and you have met all four:

So the question now is not how do I catch an error. It is what happens to the errors try...catch misses, which is four more things:

1. an error in code that runs later is not inside your try when it happens (9.3.2);
2. a catch you never read from does not need a binding at all (9.3.3);
3. a catch that handles everything hides the bugs it did not expect (9.3.4);
4. and something should still be watching when an error escapes every handler you wrote (9.3.5).

9.3.2 Errors That Escape

Section 2.5.6 named two limits of try...catch. The first was the syntax error: the program never starts, so there is no running program in which a catch could fire. The second was left for this section, because it needs functions — which you now have.

A try...catch guards the lines inside it, at the moment those lines run.

Some code does not run at the moment you write it. setTimeout(fn, ms) is the plainest example: it hands JavaScript a function and a delay, and JavaScript runs that function later, on its own. setTimeout itself returns immediately.

try {
  setTimeout(function() {
    console.log(missingValue);          // the error happens in here
  }, 1000);
} catch (err) {
  console.log("This never prints.");
}

What you should see: the catch does not run, and an uncaught ReferenceError reaches the browser one second later.

Follow the timing, because the timing is the whole explanation:

1. setTimeout is called. It schedules the function and returns straight away — it does not run it.
2. The try block is now finished. Execution leaves the whole try...catch behind.
3. One second later, JavaScript runs the scheduled function. There is no try around it any more, because that block ended in step 2.

The fix follows directly from the diagnosis. Put the try...catch where the error will be — inside the scheduled function:

setTimeout(function() {
  try {
    console.log(missingValue);
  } catch (err) {
    console.log("Caught it: " + err.name);
  }
}, 1000);

What you should see: one second later, Caught it: ReferenceError.

try {
  setTimeout(startJob, 500);
} catch (err) {
  console.log("Job failed to start.");
}

9.3.3 A catch Without Its Binding

Every catch you have written so far named the error: catch (err). That name is a binding — it binds the error object to a variable so the block can read err.name and err.message.

Sometimes the handler does not care. It is enough to know that something failed:

▶ Press Run to see the output…

What you should see:

That was not valid JSON. Using an empty object instead.
Carrying on.

Note the catch { — no parentheses, no name. This is the optional catch binding, and it is allowed exactly when the block never mentions the error object.

Leave the binding in the moment you need any detail from it — the name, the message, or the type. The next subsection needs all three.

// A
try { risky(); } catch (err) { console.log("Failed: " + err.message); }

// B
try { risky(); } catch (err) { console.log("Failed."); }

9.3.4 Rethrowing What You Do Not Recognize

Here is a catch block that looks careful and is dangerous:

▶ Press Run to see the output…

What you should see:

Bad JSON in the part file.

That message is a lie. The JSON is perfect. The real error is the typo part.nmae — a TypeError, because part.nmae is undefined and undefined has no .toUpperCase(). The catch caught it anyway, dressed it in the wrong explanation, and hid a typo that will now be very hard to find.

**A catch block catches everything thrown inside its try, not just the failure you had in mind.**

The fix is the rethrowing pattern, in three steps:

1. catch every error, as always;
2. check whether it is one you actually recognize;
3. if it is not, throw it again so it travels on to someone who does.

instanceof is how step 2 asks what kind of error is this?

▶ Press Run to see the output…

What you should see: a real, uncaught TypeError naming the actual problem, instead of a comforting sentence about JSON.

JSON.parse throws a SyntaxError when its text is malformed, so err instanceof SyntaxError is exactly the test for the failure this try was written for. Anything else is a bug somewhere in the code, and a bug wants to be seen.

A rethrown error is not necessarily fatal. If an outer try...catch is waiting, it gets its turn:

▶ Press Run to see the output…

What you should see:

Axle
loadPart: the text was not JSON.
null
Outer handler caught a TypeError

The inner handler dealt with what it knew — malformed text — and let the TypeError from null.length travel out to the outer one.

▶ Press Run to see the output…

▶ Press Run to see the output…

A measurement was out of range.

9.3.5 The Last Line of Defense

Rethrowing raises a fair question: if every handler passes an error along, where does the last one go?

It reaches the browser, which stops the script. That is the right outcome — but it happens on your machine, where you can see the console. On a visitor's machine, nobody is watching.

Browsers offer one final hook for exactly that case:

window.onerror = function(message, url, line, col, error) {
  console.log("Unhandled: " + message + " at line " + line);
};

Assign a function to window.onerror and the browser calls it for errors that escaped every try...catch. It receives five arguments:

That is the honest limit of it: by the time window.onerror runs, the work that failed has already failed. A try...catch in the right place can recover; a global handler can only tell you.

9.3.6 Debugging a Model

Everything so far has been about errors your program handles. This last part is about errors you have to handle, at the keyboard, when a model does not appear.

A model editor on these pages runs your code and paints the result. When the code throws, the canvas stays blank and the message appears in the strip underneath it, in the same two-part shape you have been reading since Chapter 2:

ReferenceError: path2 is not defined

That is a name and a message, exactly like err.name and err.message. Read it the same way: the name says what kind of mistake, the message says which value was involved.

Three symptoms cover almost every broken model.

A message naming something "is not defined". A misspelled function, or one you have not imported. cuboid exists; cubiod does not.

"Stopped: this code ran too long — check that your loop can finish." The editor gives your code five seconds and then stops it. This is nearly always a loop whose counter never reaches its limit:

// i is never increased, so i < 8 is true forever
for (let i = 0; i < 8; ) {
  parts.push(box({ size: 2 }));
}

A blank canvas with no message at all. The code ran to the end without an error and produced no geometry — usually a main that computed a shape and forgot to return it.

That last note is the technique worth keeping. When a complicated model comes out wrong, cut it down instead of staring at it: return an early piece, confirm it looks right, and add the next step back one at a time.

function main() {
  const base = box({ size: [40, 20, 5] });
  const post = tube({ radius: 3, height: 30 });

  return base;                   // check the base alone first,
  // return union(base, post);    then put this line back
}

The bug is in the first step whose result stops looking right. This is the same discipline as the spec-first flow in §9.4 — take small steps and check after each one — applied by hand instead of by a test.

Summary

• A try...catch guards a moment, not a function. Code scheduled to run later — with setTimeout, for instance — has left the block behind by the time it runs, so the try must go inside the scheduled function.
• The catch binding is optional: write catch { ... } when the handler never reads the error object, and catch (err) { ... } when it does.
• A catch catches everything thrown in its try, so a handler that explains every failure the same way hides real bugs. The rethrowing pattern — check with instanceof, handle what you recognize, throw err for the rest — keeps the explanation honest.
• A rethrown error travels to an outer try...catch if one is waiting, and to the browser if none is.
• window.onerror is the browser's last-resort handler for errors nothing caught. It receives the message, url, line, column and error object, and it reports rather than recovers.
• When a model fails, read the name-and-message under the canvas, watch for the five-second loop guard, and treat a silent blank canvas as a missing return. Narrow a broken model by returning an early piece and adding steps back one at a time.

Problem Set 9.3

setTimeout(function() {
  try {
    // the risky work happens in here
  } catch (err) {
    console.log("Caught it: " + err.name);
  }
}, 1000);

try {
  save();
} catch {
  console.log("Could not save.");
}

Key Terms