- From: Stephen McGruer <notifications@github.com>
- Date: Wed, 13 Jul 2022 12:55:13 -0700
- To: whatwg/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/webidl/issues/1168/1183618555@github.com>
@rsolomakhin - they're a somewhat* new mechanism on the web that allows asynchronous signalling that 'something' has aborted - see the [MDN article](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal). I'm not familiar with them being used as an output source from a Web API, however, only as an input to one. (That is, I'm used to them being a mechanism for the website to cause a browser operation to abort, rather than a browser operation to tell the website that it has or is aborting). I do think there are other ways we could handle this result rather than a new DOMException type, however. I personally am partial to not considering opt-out a true error and just having the Secure Payment Confirmation API have a 'type' or 'status' flag on its success return object to the calling website. That said, I am generally interested in whether we consider the set of DOMExceptions on the web 'fixed' or are still expanding it over time, and if we've put in any thought to whether DOMExceptions could carry more structured data to allow for better error handling by developers. The root of this issue was that we currently throw the same DOMException error type for two semantically different outcomes from Secure Payment Confirmation. \* Maybe not **that** new, I'm just old 🤣 -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/webidl/issues/1168#issuecomment-1183618555 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/webidl/issues/1168/1183618555@github.com>
Received on Wednesday, 13 July 2022 19:55:26 UTC