Benjamin Gruenbaum

Oh, and regarding: > I saw claims like this a few times: I can state that is not intentional, and using .name is not the recommended way. That one example...

@DerekNonGeneric this is not a confirmed bug - the fact this happens was a design decision that carefully considered the trade-offs. We can re-evaluate this further and see if we...

@DerekNonGeneric I am not arguing for/against using `DOMException`s for `AbortError`s right now - I am just asking not to change the behaviour without discussions. We _started_ with `DOMException`s and moved...

@kanongil If I understand correctly `signal.reason` doesn't replace the error does it? @Jamesernator to explain: in order for the DOM to consider not using DOMExceptions it would have to be...

Hmm, `.reason` superceding the `AbortError` is actually pretty risky since it means consumers can raise arbitrary error subclasses "from the outside" and users can't catch cancellation with `AbortError`s. I think...

@kanongil This sounds dangerous since it means users will be able to throw non-AbortErrors into controllers they own which means the contract for "what this method rejects with" changes from...

Hmm, this seems rather unfortunate. Intuitively I'd prefer it if it was only possible to abort with subclasses of `DOMException` AbortErrors even if that'd force Node.js to use `DOMException`s in...

@domenic and how are users expected to distinguish cancellation from other (operational) errors? Is there a best practice we should follow here?

@jasnell pointed out that `.reason` does not imply/suggest/guarantee that it is the exception thrown when a promise API is rejected. So I think my current ask in this regard is...

@jasnell Node.js moved _from_ DOMEXceptions for vendoring reasons (so that readable-stream would not need to vendor DOMExcepiton). If that concern has been resolved we can _revert_ that decision.