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

I also don't see it as breaking in the general case. Node.js has, for some time, used our own `AbortError` instance to signal cancelations, and it *will* be breaking for Node.js users if/when we start switching those specific cases to use `signal.reason` or `DOMException(AbortErr)`, but that's a Node.js-specific implementation detail. We'd just need to walk changes there through a proper deprecation cycle. 

Node.js (and any application) is at liberty to ignore the new `signal.reason` if they wish. That will be the case, for instance, for any existing code in the wild that was deployed before `reason` was added. We shouldn't expect those to be updated and we can't really depend on `signal.reason` being used at all. Code written *after* reason was introduced should start making use of it and where those two cases intersect, yes, there may be some edge cases where devs might have to jump through a few hoops.

Where developers might need to bridge those environments, at least in Node.js, it would be a good idea for Node.js' `AbortError` to support the `cause` option. That would at least give us the option of doing something like `new AbortError('it was canceled!', { cause: signal.reason })` ---- For that matter, it would be a good idea for `new DOMException()` to support specifying the `cause` also, but that's a separate conversation).



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