Re: [whatwg/dom] Add a way to identify Abort errors originating from controllers (Issue #1033)

> still needs to observe cancellation.

Let's be clear: the use case being asked here is *not* observing cancelation. It's observing who caused an arbitrary exception.

In the following example:

```js
const controller = new AbortController();

const resultPromise = fetch(url, { signal: controller.signal });

setTimeout(() => {
  controller.abort(new TypeError("actually, it turns out the URL was bad in some application-specific sense, and we didn't validate it until now!"));
}, 10);
```

`resultPromise` is *not* being canceled. It is failing, with a `TypeError`, because `url` was invalid. _The fact that this is coming from the `controller`, instead of from `fetch()`, is irrelevant_.

Code that cares about cancelations (abortions) should check for `e.name === "AbortError"`. Code that cares about timeouts should check for `e.name === "TimeoutError"`. Code that cares about input validation errors should check for `e.name === "TypeError"`. _It doesn't matter whether that came from the controller, or the `fetch()` implementation itself._ For example, if instead of checking for `e.name === "AbortError"`, you checked for `e === signal.reason`, you would miss aborted fetches due to other parts of the `fetch()` spec, e.g. those due to the page unloading or the body stream being canceled.

Fundamentally, code which is inspecting the implementation details of _how_ a given exception appeared, is unsound. I like @Jamesernator's comparison to stack inspection; you shouldn't need to do either such thing in order to handle exceptions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1033#issuecomment-980846806