Handling Errors Across async Flows

Five strategies cover almost everything, and choosing between them is the real skill.

Catch at the boundary. Handle the failure where the operation started, not deep in the call chain. The lowest layer reports the failure, and the layer that owns the user experience decides what to do about it.

Time out. Any operation that waits on the network needs a deadline, because a request that never resolves is worse than one that fails quickly. A timeout is usually built by racing the real promise against a timer.

Retry. Some failures are transient, such as a dropped connection or a rate limit, and a retry with a growing delay recovers from them. The important rule is to retry only failures that are worth retrying, and to cap the number of attempts.

Collect partial results. When several independent operations run together and you want all of them, the settled combinator reports each outcome separately so one failure does not discard the successes.

Fail fast where it matters. If the operation cannot continue without one particular result, use the strict combinator so you do not wait for work whose result will be thrown away.

Two things to keep in mind while choosing. The place where you catch determines where the error is visible, so catching too low hides failures and catching too high turns a recoverable problem into a dead request. And whatever you do, a retry loop needs a bound, because an unbounded retry against a failing service is an outage of your own making.

Both helpers are small and both are worth writing once and reusing. The timeout races the operation against a timer, and the retry wraps an operation so it is attempted again on failure.

// A timeout built on the race combinator.
const withTimeout = (promise, ms, message = "Timed out") => {
  let timer;
  const timeout = new Promise((_, reject) => {
    timer = setTimeout(() => reject(new Error(message)), ms);
  });

  return Promise.race([promise, timeout]).finally(() => clearTimeout(timer));
};

// A retry that only retries transient failures.
const withRetry = (operation, attempts = 3, delayMs = 20) => {
  return operation().catch((err) => {
    if (attempts <= 1) throw err;
    return new Promise((resolve) => setTimeout(resolve, delayMs))
      .then(() => withRetry(operation, attempts - 1, delayMs));
  });
};

let tries = 0;
const flaky = () => {
  tries += 1;
  return tries < 3 ? Promise.reject(new Error("temporary")) : Promise.resolve("worked");
};

withRetry(flaky)
  .then((value) => console.log("result:", value, "tries:", tries))
  .catch((err) => console.log("gave up:", err.message));

// A timeout on a slow operation.
withTimeout(new Promise((resolve) => setTimeout(() => resolve("slow"), 200)), 50)
  .then((value) => console.log("resolved:", value))
  .catch((err) => console.log("failed:", err.message));

The finally in the timeout helper is what stops the timer from keeping the process alive after the operation has finished, which is an easy bug to ship and a slow one to notice.

The retry helper waits between attempts rather than retrying immediately, because hammering a service that is already struggling makes the problem worse. A real implementation would use a growing delay and would only retry the errors that are worth retrying, which means checking the error rather than retrying every rejection.

Two warnings. The timeout does not cancel the underlying operation; it only stops waiting for it, so the work may still complete in the background. And a retry multiplies the load on your service, so keep the attempt count small unless you know the failure is genuinely transient.

When the operations are independent and you want every outcome rather than the first failure, the settled combinator is the right tool. Each result carries its own status.

const ok = (value) => Promise.resolve(value);
const fail = (message) => Promise.reject(new Error(message));

const tasks = [ok("profile"), fail("settings"), ok("orders")];

Promise.allSettled(tasks).then((results) => {
  for (const result of results) {
    if (result.status === "fulfilled") {
      console.log("ok:", result.value);
    } else {
      console.log("failed:", result.reason.message);
    }
  }

  const succeeded = results.filter((r) => r.status === "fulfilled");
  const failed = results.filter((r) => r.status === "rejected");

  console.log("counts:", succeeded.length, failed.length);   // 2 1
});

The important property is that the overall promise never rejects. That means one failing task cannot cancel the others, and the code after it always runs. With the strict combinator instead, the first rejection would reject the whole thing and you would lose the results of the operations that had already succeeded.

Two patterns are worth naming. The first is a dashboard, where each panel loads independently and a failed panel shows its own error while the others render normally. The second is a bulk operation, such as sending a batch of messages, where you want to report which ones failed so they can be retried individually.

One subtlety to be aware of. The settled combinator waits for every promise, including any that never settle at all. If one of your operations can hang, add a timeout to it before you combine the results, or the whole batch waits forever. That is the reason the timeout helper from the previous question exists as a separate concern.