In JavaScript, when work is cancelled through an AbortSignal, what error surfaces, and how do you tell that cancellation apart from a genuine failure inside a catch block?

## The rejection value is the reason There is no separate cancellation channel. A cooperating operation rejects its promise, and the rejection value is whatever `signal.reason` holds. That single rule explains every case: ```js const c = new AbortController(); c.abort(); console.log(c.signal.reason.name); // "AbortError" const custom = new AbortController(); custom.abort(new Error('user left the page')); console.log(custom.signal.reason.message); // "user left the page" ``` - `abort()` with no argument stores a `DOMException` whose `name` is `"AbortError"`. This is the default the whole ecosystem keys off. - `abort(value)` stores `value` verbatim. It is not wrapped, not coerced, not copied. If you pass a string, the promise rejects with a string. - `signal.throwIfAborted()` throws that same value, so a pre-check inside your own code produces the identical error a listener would. - `AbortSignal.timeout(ms)` aborts itself with a `DOMException` named `"TimeoutError"` — a deliberately different name, because a deadline expiring is a different event from a caller changing its mind. ## Detecting cancellation in catch Three checks, in rough order of preference: ```js try { await doWork(input, { signal }); } catch (err) { if (signal.aborted && err === signal.reason) { return; // definitely our cancellation } if (err?.name === 'AbortError') { return; // cancellation from a signal we may not own } throw err; // a real failure } ``` 1. **Identity against your own signal** (`err === signal.reason`) is the strongest test when you own the controller: it proves this rejection came from *your* cancellation and not from an unrelated abort deeper in the stack. 2. **`err?.name === 'AbortError'`** is the portable check. Use optional chaining, because a rejection value is not guaranteed to be an object at all — someone may have aborted with a string or `undefined`. 3. **`signal.aborted`** alone tells you a cancellation happened, but not that *this* error is it; a genuine failure can occur in the same window. Prefer it as a supporting check. What not to do: - **Do not match the message.** `"The operation was aborted"`, `"signal is aborted without reason"` and similar strings differ across engines and versions. Matching them is a latent bug. - **Do not rely on `err instanceof Error`** to classify. A custom reason can be any value, and class checks on host exception types are a poor discriminator compared with `name`. - **Do not rely on `instanceof DOMException`** if the value may have crossed a realm boundary such as a worker or iframe, where the constructor differs. ## Custom reasons Passing your own reason is genuinely useful when several things can cancel the same work: ```js controller.abort(new DOMException('Navigation', 'AbortError')); ``` Keeping `name` as `"AbortError"` means generic handlers up the stack still recognise it as a cancellation, while your `message` carries the local detail. A plain `new Error('cancelled')` breaks that: its `name` is `"Error"`, so every library that filters on `AbortError` will now report your cancellation as a failure. ## Why the distinction earns its keep Cancellation is an *expected* outcome of normal use — a user navigates away, a component unmounts, a newer request supersedes an older one. Failures are not. Conflating them produces concrete damage: - Error-reporting tools fill with `AbortError` noise, drowning real incidents and burning quota. - Retry logic re-runs work the caller explicitly asked to stop, which is at best waste and at worst a correctness bug for non-idempotent operations. - The UI shows "something went wrong" for an action the user themselves cancelled. The conventional handling is therefore asymmetric: swallow or quietly return on cancellation, and let everything else propagate. ## The finally trap A `finally` block runs on abort just as on success, so cleanup happens either way — but be careful about what you do there. Updating shared state or a cache from a `finally` after cancellation can resurrect work the caller cancelled; re-checking `signal.aborted` before committing anything is the safe pattern. ## Aborts still need handlers Because cancellation is delivered as a rejection, an aborted operation with no rejection handler is an unhandled rejection like any other. "It was only cancelled" is not an exemption — the fire-and-forget call still needs a `.catch`.