Error handling strategies

Plan what happens when code fails

The last two lessons, try, catch & finally and Throwing & custom errors, showed the tools. You can catch an error, throw a clearer one, keep the first error as its cause, and clean up. This lesson asks a new question: what should your program do after something goes wrong?

Good programs still have errors. The difference is what they do next. A good program:

• stops in the right place,
• keeps the user safe,
• saves enough details for a developer to fix the bug,
• and keeps a small problem from growing into a big one.

Sometimes the right move is to stop at once. Sometimes it is to show a simpler version of the page. Sometimes a function should hand back an object that says "this failed", without throwing at all.

The table below lists five plans. Read each row from left to right: the plan, when to pick it, and what your code does.

A promise is an object for a result that arrives later. This lesson uses promises only once, in a short paragraph about the unhandledrejection event. The Promises lessons in Stage 6 teach them in full.

Fail fast means: stop as soon as your code sees data it can't trust. Throw an error and end the current task. Here are three examples where guessing would be dangerous:

• a checkout total that is not a number,
• a missing security token on a form,
• a settings file that makes no sense.

Stopping early keeps the bug small and easy to see. If the code kept going, the bad data could spread to other places first.

Recover means: keep going, but with less. The page stays honest about what it can do. Some examples:

• A missing profile photo becomes the first letter of the name.
• A saved color theme that can't be read becomes the default theme.
• A broken "recommended for you" box disappears, and the article is still readable.

The simpler thing you show instead is called a fallback.

const user = { name: "Asha", avatarUrl: "" };
const avatar = user.avatarUrl || user.name[0];
console.log(avatar);

1. Line 1 makes a user whose avatarUrl (the photo address) is an empty string.
2. Line 2 uses || (or). An empty string counts as false, so || picks the right side: user.name[0], the first letter, "A".
3. Line 3 prints A.

The next demo reads a config: a small piece of JSON text with an app's settings. This config has no endpoint (the web address the app sends data to). The same function can handle that in two modes:

• Strict mode fails fast: it throws an error.
• Lenient mode recovers: it uses default values and adds a warning.

Both are fine plans. Which one is right depends on the app.

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"
}

The best place to catch an error is close to where it happens. There, your code knows enough to fix the problem or explain it to the user.

Sometimes no code catches an error. The browser gives you one last place to hear about it: a global handler. It is a function that runs for any error that nobody caught.

You set one up with window.addEventListener("error", handler). That line means "when an error event happens on the page, call handler". An event is a message the browser sends when something happens. The handler gets an object with details, such as:

• message: the error text,
• filename: the file the error came from,
• lineno: the line number.

Two things to remember:

• window exists only in the browser. A Node script doesn't have it.
• A global handler only reports the error. It does not make the failed task work. Keep catching errors close to where they happen.

The browser has a second event, unhandledrejection. A promise rejects when its work fails. If no code handles that failure, the browser sends this event. Here is the smallest example: Promise.reject(new Error("No handler"));. It makes a promise that has already failed, and nothing handles it. You don't need to understand promises yet. Just remember: this event is the promise version of the error event.

The lab below runs inside an iframe: a small page inside this page. The errors it makes stay inside that small page, so they can't break the lesson.

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});

A page is often built from small parts called widgets, like a sales box or an alerts box. To render a widget means to build what it shows on the screen.

An error boundary is a try/catch wrapped around one widget's render. If that widget throws, the boundary shows a simple fallback in its place. The rest of the page still shows up.

React, a popular tool for building pages, has its own error boundary feature. This course hasn't taught React yet, so the demo uses plain JavaScript. It has three widgets: Sales, Alerts, and Uptime. The Alerts widget throws. Each widget gets its own boundary.

In React, an error boundary only catches errors that happen while the page is being built. It does not catch errors in:

• click handlers and other event handlers,
• timers, such as setTimeout,
• code that runs later, after the page is built.

Catch those errors in their own code.

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);Run

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 log is a saved record of what happened in your app. If you catch an error but nobody can tell what went wrong, the job is only half done. A good error log answers these questions:

• What failed? (the message)
• Where in the code? (the stack, the list of function calls that led to the error)
• On which page, and after which click or action?
• In which release, meaning which version of the app?

Logs must also be safe. Never put these in a log:

• passwords,
• tokens (secret codes that prove who a user is),
• other secrets, card numbers, or private details about a person.

To redact a value means to replace it with a marker like [redacted] before saving it.

Some errors happen thousands of times. You can sample them: save only some copies, enough to understand the problem.

A monitoring service, such as Sentry, collects errors from many users. It groups the same error together, alerts your team, and shows which release each error came from. Your code still decides what is safe to send.

The user needs something different from the log: a short, clear next step. For a failed save, show We couldn't save your changes. Try again. Keep the message, stack, page, and release in the log. Never leave a catch block empty. If you can't recover, log the error or throw it again, so the problem doesn't disappear.

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",
  };
}

function userMessageFor(error) {
  return error.message ? "We couldn't save your changes. Try again." : "Something went wrong. Try again.";
}

const log = logError(new Error("database detail"), { authToken: "secret", route: "/settings" });
console.log(log.context.authToken, userMessageFor(new Error("database detail")));

1. Lines 1–7, redactSecrets: line 2 copies the context with { ...context }, so the original object stays the same.
2. Line 3 loops over every key in the copy. Line 4 checks each key name with /token|password|secret/i. It matches any key that contains "token", "password", or "secret". The i means capital letters count too, so authToken matches. A match is replaced with "[redacted]".
3. Lines 9–16, logError: it builds the log with the message, the stack, the safe context, and the release.
4. Lines 18–20, userMessageFor: it picks the short text the user sees.
5. Line 23 prints [redacted] We couldn't save your changes. Try again.

Throwing is a good fit for surprises and bugs. But some failures are normal and expected:

• Text a user typed may not be valid JSON.
• A search may find nothing.
• A save may fail twice before it works.

For these, a function can return a result object instead of throwing. It always has an ok property:

• { ok: true, value } means it worked. value is the answer.
• { ok: false, error } means it failed. error says why.

The code that called the function checks ok first, then uses value or error.

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 also work well with small helper functions. A retry helper calls a task again when it fails. It stops at the first result with ok: true. No throwing is needed to end the loop.

Only retry temporary failures, such as a network that is down for a moment. Don't retry a failure that will happen every time, such as a wrong password. The code below marks a temporary error with transient: true ("transient" means short-lived).

A good retry also waits longer before each new try: 100 ms, then 200 ms, then 400 ms. This is called exponential backoff. Always stop after a small number of tries.

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;
    if (!result.error.transient) return result;
    if (attempt < attempts) {
      const delayMs = 100 * 2 ** (attempt - 1);
      console.log("retry after", delayMs, "ms");
    }
  }
  return last;
}

let tries = 0;
function operation() {
  tries += 1;
  return tries < 3
    ? { ok: false, error: Object.assign(new Error("offline"), { transient: true }) }
    : { ok: true, value: "saved" };
}

const result = retry(operation);
console.log(result.value, tries);

1. Line 4 runs the task once and keeps its result object.
2. Line 5: if ok is true, return the result. We're done.
3. Line 6 remembers the last failure, in case every try fails.
4. Line 7: if the error is not temporary, stop now. Trying again won't help.
5. Lines 8–11: if there are tries left, work out the wait. 2 ** (attempt - 1) means 2 to the power of attempt - 1, so the waits are 100, then 200. This demo only prints the wait; it doesn't really pause.
6. Lines 16–22, operation: it fails twice with a temporary "offline" error, then returns { ok: true, value: "saved" }. Object.assign adds transient: true to the error.
7. Line 24 starts the retry. Line 10 prints retry after 100 ms, then retry after 200 ms. The third try works, so line 25 prints saved 3.

Where you’ll use this

You'll pick an error plan wherever your code works with users, data, or other servers. The rule: catch the error at the closest place that can make a good choice. Errors you didn't expect can go up to a boundary or a global handler, which reports them.

Read each row as: in this part of an app, this plan usually fits, and here is what it looks like.

To practice reading error messages and the stack, see the Reading errors and Debugging lessons. A closure can help you build a logger that remembers the release; see the Closures lesson.

Common misconceptions

• “If I catch it, it’s fixed.” Not quite. A catch block must do one of three things: recover honestly, add details and throw again, or log the error safely.
• “A global handler means I don’t need my own catch blocks.” Not quite. A global handler runs last. By then it is usually too late to recover in a specific way.
• “Always recover if you can.” Not quite. Recovering with unsafe data is worse than stopping with a clear error.
• “Error boundaries are only a React thing.” Not quite. React has a feature with that name, but the idea works anywhere: keep one broken part of the page from breaking the rest.
• “Log everything.” Not quite. Log enough to find the bug. Hide secrets, and save only some copies of an error that repeats a lot.
• “Result objects are always better than throwing.” Not quite. Use them for failures you expect. Throw for bugs and for data that should never happen.

Key takeaways

• Fail fast when going on would spread bad data, hide a bug, or be unsafe.
• Recover when there is an honest fallback, such as a default or a simpler page.
• Global error and unhandledrejection handlers report errors nobody caught. They don't replace your own catch blocks.
• An error boundary keeps one broken part of the page from breaking the rest.
• A good log has the message, stack, page, user action, and release. Hide secrets first.
• A result object says plainly whether a call worked: { ok: true, value } or { ok: false, error }.

An error handling strategy means: catch each error at the closest place that can make a safe choice, and report everything else clearly.

Up next: Synchronous vs asynchronous.