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

@ronag that is likely what we'll do but that is not the guidance and in my experience when there were misunderstandings like this it was 90% just a misunderstanding. Intuitively this indeed does greatly increase the API surface of all of our APIs taking signals.

The guidance to `throw signal.reason` makes sense for stuff like `AbortSignal.timeout` since it means that APIs like fetch don't need to change and it's a generic mechanism to throw exceptions _into_ stuff./ 

@jasnell note that in this case `signal.addEventListener('abort'` consuming code is expected to `throw signal.reason` and not `throw new AbortError('...', { cause: signal.reason })`. The spec is pretty specific:

> Convey that the operation got aborted by rejecting the promise with AbortSignal object’s abort reason.

So while we _can_ keep `throw new AbortError('...', { cause: signal.reason })` because our APIs (like `fs.readFile` aren't web APIs) that does _not_ move Node.js closer to the web platform nor does it enable universal code nearly as much.


-- 
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-981106322