Gil Pedersen

This is the only bug report I have filed for the issue. Let me know if I can help.

@benjamingr That design does not appear to have been revised when node added support for native `DOMException`. This is causing extra confusion, and the root of this issue. Essentially, this...

Thanks for the thorough response, and good to know that there is still room for iterating the approach. `DOMException` has only just been made public with node v17, so has...

We agree that it makes sense for user code to distinguish `AbortError` from regular errors, eg. to avoid logging it, right? Thus it makes sense that the error included in...

`signal.reason` seems like a very sensible API, and has already been merged in https://github.com/whatwg/dom/pull/1027. Using this in node would make the `readable-stream` issue moot, since the associated abort logic would...

@benjamingr Yes, it should replace the generated error, as [specified here](https://github.com/whatwg/dom/blob/4ca187f9ccd4b1548d87293307ee58430ef4908b/dom.bs#L1896-L1897).

In most cases the user will also be the one calling `.abort()` on the `AbortController`, in which case it is not a problem, but a feature. Eg. a test case...

@benjamingr Yeah, I guess it could cause an issue for code that wants to test for this, like: ```js try { await fetch(…, { signal }); } catch (err) {...

FYI, there are plans to signal some aborts using `new DOMException("TimeoutError")` as well: https://github.com/whatwg/dom/issues/951#issuecomment-922833719

@Jamesernator There is still the case where some intermediate logic (that you might not control) wants to handle abort errors in a special way, as in https://github.com/nodejs/node/issues/40692#issuecomment-972712108. However, this is...