Error handling strategies

Strategy before syntax

The previous lessons, try, catch & finally and Throwing & custom errors, taught the mechanics: catch a failure, throw a better one, attach a cause, and clean up. This lesson answers the next question: what should happen after something goes wrong?

Professional JavaScript is not error-free JavaScript. It is code that fails in the right place, keeps users safe, reports enough information to fix the bug, and avoids turning a small problem into a bigger one. Sometimes that means stopping immediately. Sometimes it means showing a fallback. Sometimes it means returning an object that says failure without throwing at all.

We will keep promises small here: unhandledrejection gets one practical paragraph and a tiny Promise.reject demo. The full promise model comes later in Stage 6, in the Promises and Error handling with promises lessons.

Fail fast means stop as soon as code detects an unsafe state. It is not pessimism; it is containment. A bad checkout total, a missing security token, or an impossible configuration should not be guessed around. Throw, stop the current operation, and make the bug visible while it is still small.

Recovering means the program can continue honestly in a reduced mode. A missing avatar can become initials. A saved theme preference can fall back to the default theme. A recommendations panel can disappear while the article remains readable.

The playground below parses a small configuration. Strict mode throws when required data is missing. Lenient mode uses defaults and returns a warning. Both are valid strategies in different products.

1const defaults = { endpoint: "/api", retries: 3, cache: false };Run2 3function parseConfig(text, mode) {4  try {5    const draft = JSON.parse(text);6    if (typeof draft.endpoint !== "string") throw new Error("endpoint is required");7    if (!Number.isInteger(draft.retries) || draft.retries < 0) throw new Error("retries must be a non-negative integer");8    return { ok: true, config: { ...defaults, ...draft }, warnings: [] };9  } catch (error) {10    if (mode === "strict") throw error;11    return { ok: true, config: defaults, warnings: [error.message] };12  }13}14 15parseConfig("{ \"retries\": 2, \"cache\": true }", "strict");

1const defaults = { endpoint: "/api", retries: 3, cache: false };2 3function parseConfig(text, mode) {4  try {5    const draft = JSON.parse(text);6    if (typeof draft.endpoint !== "string") throw new Error("endpoint is required");7    if (!Number.isInteger(draft.retries) || draft.retries < 0) throw new Error("retries must be a non-negative integer");8    return { ok: true, config: { ...defaults, ...draft }, warnings: [] };9  } catch (error) {10    if (mode === "strict") throw error;11    return { ok: true, config: defaults, warnings: [error.message] };12  }13}

{ "retries": 2, "cache": true }

{
  "ok": false,
  "error": "endpoint is required"
}

Local code should catch errors where it has enough context to recover or explain the problem. A browser global handler is the last safety net after that local handling did not happen. In most browsers, window.addEventListener("error", handler) receives an uncaught error event with fields such as message, filename, and lineno.

A second browser event, unhandledrejection, reports a Promise that rejects and is not handled. Minimal example: Promise.reject(new Error("No handler"));. Do not worry if promises still feel mysterious; they are taught in Stage 6. For now, remember that this event is the promise-shaped version of the central alarm panel.

1window.addEventListener("error", (event) => {2  parent.postMessage({3    kind: "error",4    message: event.message,5    filename: event.filename,6    lineno: event.lineno,7  }, "*");8});9 10window.addEventListener("unhandledrejection", (event) => {11  parent.postMessage({12    kind: "unhandledrejection",13    reason: String(event.reason && event.reason.message || event.reason),14  }, "*");15});

An error boundary is a protective wrapper around a region of UI. In a framework, you can think of it as a component-level try/catch for rendering: if one child fails, the boundary shows a fallback for that area instead of letting the whole screen disappear.

React has a formal error-boundary feature, but this course has not taught React yet. So the demo uses plain JavaScript: three widget render functions, one of which throws. The boundary wraps each widget separately.

1function renderWidget(widget) {2  return "<article>" + widget.title + ": " + widget.render() + "</article>";3}4 5function renderWithBoundary(widget) {6  try {7    return renderWidget(widget);8  } catch (error) {9    return "<article>" + widget.title + ": temporarily unavailable</article>";10  }11}Run12 13widgets.map(renderWithBoundary);

1function renderWidget(widget) {2  return "<article>" + widget.title + ": " + widget.render() + "</article>";3}4 5function renderWithBoundary(widget) {6  try {7    return renderWidget(widget);8  } catch (error) {9    return "<article>" + widget.title + ": temporarily unavailable</article>";10  }11}12 13widgets.map(renderWithBoundary);

A handled error that nobody can diagnose is only half handled. Good logging answers: what failed, where, during which user action, in which release, and with what safe context? Useful fields include message, stack, route or screen, user action, feature flag, browser information when available, and release version.

Logs must also be safe. Do not send passwords, tokens, secrets, credit card data, or full personal data just because it was nearby. Redact first, sample repeated noise when volume is high, and use monitoring services such as Sentry or similar tools neutrally: they collect, group, alert, and connect events to releases; your code still decides what is appropriate to send.

function redactSecrets(context) {
  const clone = { ...context };
  for (const key of Object.keys(clone)) {
    if (/token|password|secret/i.test(key)) clone[key] = "[redacted]";
  }
  return clone;
}

function logError(error, context) {
  return {
    message: error.message,
    stack: error.stack,
    context: redactSecrets(context),
    release: "2026.09.25",
  };
}

Throwing is excellent for surprising failures and invalid states. But some failures are expected: user text may not be valid JSON, a search may find no match, a retryable operation may fail twice before succeeding. In those cases, a result object can make the success and failure paths explicit.

1function tryParse(text) {2  try {3    return { ok: true, value: JSON.parse(text) };4  } catch (error) {5    return { ok: false, error };6  }7}8 9const result = tryParse('{ "name": "Ada" }');Run10if (result.ok) {11  console.log(result.value.name);12}

1function tryParse(text) {2  try {3    return { ok: true, value: JSON.parse(text) };4  } catch (error) {5    return { ok: false, error };6  }7}8 9const result = tryParse('{ "name": "Ada" }');10if (result.ok) {11  console.log(result.value.name);12}

{
  "ok": true,
  "value": {
    "name": "Ada"
  }
}

Result objects combine well with small helpers. A retry helper can call an operation several times and stop at the first ok: true result without using exceptions as loop control.

function retry(operation, attempts = 3) {
  let last;
  for (let attempt = 1; attempt <= attempts; attempt += 1) {
    const result = operation();
    if (result.ok) return result;
    last = result;
  }
  return last;
}

Where you’ll use this

Error strategy shows up anywhere JavaScript talks to users, data, or other systems. The pattern is to catch as close as possible to the place that can make a good decision, then let truly unexpected failures rise to a boundary or global handler for reporting.

If you want to revisit reading stack traces, the published Reading errors and Debugging lessons are good companions. Closures can also help when you create a logger that remembers release information; see the Closures lesson.

Common misconceptions

• “Catching means fixed.” A catch block must recover honestly, add context and rethrow, or report safely.
• “Global handlers can replace local handling.” They are final alarms, usually too late for specific recovery.
• “Recover whenever possible.” Unsafe recovery is worse than a loud failure.
• “Error boundaries are only a React trick.” React has an API, but the idea is broader: isolate one UI region.
• “Log everything.” Log enough to debug, but redact secrets and sample noisy repeats.
• “Result objects are always better than throws.” Use them for expected failures; throw for impossible states and bugs.

Key takeaways

• Fail fast when continuing would corrupt data, hide a bug, or be unsafe.
• Recover when there is a truthful fallback or reduced mode.
• Global error and unhandledrejection handlers are final reporting alarms, not a replacement for local strategy.
• Error boundaries isolate one UI region so the rest can keep working.
• Logs should include message, stack, context, user action, and release, with secrets redacted.
• Result objects make expected success and failure explicit: { ok: true, value } or { ok: false, error }.

Error handling strategy means catching failures at the narrowest place that can make a safe decision, and reporting everything else clearly.

Up next: Synchronous vs asynchronous.