Error handling & debugging

The first pass at errors covered try/catch/finally, custom Error subclasses, and reading a stack trace. This is what's past that: chaining errors together, what happens to a rejection nobody catches, why immutability keeps coming up in framework code, and debugging tools past console.log.

Error chaining with cause

Catching a low-level error and throwing a more meaningful one is normal — but doing that used to destroy the original error entirely. The cause option keeps it attached.

function loadUser() {
  try {
    JSON.parse("not valid json");
  } catch (dbError) {
    throw new Error("failed to load user", { cause: dbError });
  }
}

try {
  loadUser();
} catch (e) {
  console.log(e.message);
  console.log(e.cause.message);   // what happens?
}

"failed to load user", then the original SyntaxError's message. Without cause, that original error is just gone — whoever's debugging this in production sees "failed to load user" and has to guess why. With it, e.cause carries the full original error (and its own stack trace) all the way up, however many layers re-throw in between.

Dry run: tracing loadUser()'s catch and cause chain

Two separate try/catch pairs, two separate errors — cause is what lets the second error carry a live reference to the first instead of replacing it outright.

Unhandled promise rejections

A rejected promise with no .catch() anywhere in its chain doesn't fail silently — it surfaces as a top-level unhandledrejection event (the same mechanism this site's own code runner listens to, to show you an error even from code with no explicit catch at all).

window.addEventListener("unhandledrejection", (event) => {
  console.error("Unhandled:", event.reason);
  event.preventDefault();   // stops it from also logging as a browser console error
});

window.onerror — the other global handler

window.addEventListener("error", (event) => {
  console.error("Uncaught:", event.message, "at", event.filename + ":" + event.lineno);
  event.preventDefault();
});

unhandledrejection above only catches promise rejections nobody caught. This sibling event catches everything else that escapes uncaught — a thrown error inside a plain synchronous function, a syntax error in a dynamically loaded script, an error thrown inside a setTimeout callback. Between the two, nothing that goes wrong in the page is ever completely invisible — which is exactly the mechanism error-reporting services build on to know a production user hit a crash at all.

AggregateError — when there's more than one error to report

try {
  await Promise.any([
    fetch("/mirror-1/health"),
    fetch("/mirror-2/health"),
  ]);
} catch (err) {
  console.log(err instanceof AggregateError);   // true — every candidate failed
  console.log(err.errors.length);                // one entry per rejected promise, in order
  err.errors.forEach((e) => console.log(" -", e.message));
}

A normal catch only ever gets one error, because a normal throw only ever carries one. AggregateError — what Promise.any rejects with when every candidate fails — is the built-in shape for "several independent things went wrong at once": it's a real Error (has .message and .stack) that additionally carries the full list in .errors, instead of forcing you to pick just one to report and silently drop the rest.

Immutability — why frameworks care so much

React, Redux, and similar tools decide "did this change?" with a single === check, not a deep comparison — because a deep comparison of a large tree, on every single render, is far too slow to do constantly.

const state1 = { count: 0 };

function mutateInPlace(state) {
  state.count++;
  return state;
}
function updateImmutably(state) {
  return { ...state, count: state.count + 1 };
}

const afterMutate = mutateInPlace(state1);
console.log(state1 === afterMutate);   // what happens?

const state2 = { count: 0 };
const afterUpdate = updateImmutably(state2);
console.log(state2 === afterUpdate);   // what happens?

true, then false. Mutating in place changes the same object — a === check comparing the old reference to the new one sees no difference at all and a framework built on that check will skip re-rendering, even though the data genuinely changed. Building a fresh object every update guarantees a new reference exactly when something actually changed — which is the entire reason "don't mutate state directly" is a rule in React, not just a style preference.

const frozen = Object.freeze({ a: 1 });
frozen.a = 2;             // non-strict script: fails silently, "a" stays 1
                            // strict mode / modules (the normal case today): throws a TypeError
console.log(frozen.a);    // 1 either way — the object never actually changed

Debugging, past console.log

Once paused at any breakpoint, the call stack panel shows the exact chain of calls that got you there — the same information a .stack string gives you after the fact, except you can now inspect every live variable at every level of it, not just read a frozen snapshot of what the values were.