Handling errors in Promises and async/await

Goal

Every rejected promise is either handled where something useful can be done, or surfaced as a logged failure with context. None is silently dropped, and none takes the process down by surprise.

Prerequisites

An async function always returns a promise: a throw inside becomes a rejection, and await on a rejected promise rethrows at that point (MDN). Know the runtime's policy for rejections nobody handles: browsers fire an unhandledrejection event on window; Node.js, with the default --unhandled-rejections=throw, raises it as an uncaught exception, which terminates the process unless handled.

Steps

1. For each awaited call decide whether the caller can recover (retry, fall back, show a message). Only then wrap it: try { data = await load(); } catch (e) { ... } around the statements that can fail, not around the whole function.
2. When you cannot recover, let the rejection propagate, or rethrow a more specific error that keeps the original attached (new Error("profile load failed", { cause: e })) so the stack survives.
3. Never leave a promise floating. A call without await, return or .catch is a rejection nobody owns; enable a lint rule that flags unawaited promises and fix every hit.
4. Do not mix .then() chains and await in one function; a missing return inside .then hides the failure from the surrounding try.
5. For concurrent work choose deliberately: Promise.all when one failure invalidates the batch, Promise.allSettled when partial results are useful. Either way every input promise gets a handler, so later failures do not become unhandled.
6. Register a last-resort handler that logs the reason and the promise's origin: window.addEventListener("unhandledrejection", ...) in the browser, process.on("unhandledRejection", ...) in Node.js. In a server process, log and exit rather than continue with unknown state.
7. Always reject with Error instances; a rejected string has no stack trace and no cause.
8. Write a test for each documented failure path that asserts the rejection type and message.

Expected result

Failures appear once, in one log line with context, at the layer that decided what to do about them. CI runs show no unhandled rejection warnings.

Limits and test basis

Cancellation is not an error condition; an AbortError from a cancelled fetch should be recognised and ignored, not reported. The described behaviour follows the cited documentation; no measurement is claimed.