-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New error name: OptOutError #1168
Comments
I’m curious whether use of multiple AbortSignals has been considered? That’s how I’ve ended up handling similar cases in userland generally and it permits assurances / control flow that an error code doesn’t. |
Not familiar with |
@rsolomakhin - they're a somewhat* new mechanism on the web that allows asynchronous signalling that 'something' has aborted - see the MDN article. 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 🤣 |
AbortController & AbortSignal are the web platform’s generic cancellation primitives. Some examples of their use in other specs:
I don’t know if they’re appropriate here, but I’d figured you were already using them because I’d (perhaps mistakenly) believed new platform APIs were only producing AbortError DOMExceptions now when leveraging those APIs.
AFAIK several of these, like WebAuthn, use them this way (e.g. user bailed from mediation UI). |
In general I would say they can be expanded, but be conservative and avoid doing so when possible. Another case that expanded them for similar reasons is https://wicg.github.io/serial/ (Ctrl+F "BreakError", "FramingError", etc.), although they did not do the correct thing that you are doing here and open a Web IDL issue.
This has been discussed in the past. I can't find where (seems to not be on the issue tracker). I think it's pretty doable these days. It would require the following work:
|
See discussion in #1168 (comment). This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
See discussion in #1168 (comment). This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
I'm working on spec'ing and implementing a new error type for SPC's opt-out case (discussed at the top of this issue), so we can change it from AbortError. @domenic I see you have a PR open to formalize this, thank you! For our SPC opt-out case, do you think we should have a specific
since we don't need any special attributes. |
If you don't need anything special, extend the error names table. No need to add another global for that. |
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Also be clearer about how exception names are meant to be used, at least for now (pending discussion in #1219). See discussion in #1168 (comment). Closes #1223. This also includes some updates to all exception creation and throwing, such as reflecting how messages are actually passed along in practice, or using Web IDL infrastructure to create DOMException instances instead of Construct()ing them.
Hello,
Would it be possible to add an "OptOutError" to the list of DOMException error names?
SPC is experimenting with opt out support by returning an "AbortError: User has opted out of the process", but many different error conditions can return "AbortError" and checking for the error message is generally considered brittle. Perhaps an "OptOutError" can be used by other APIs that allow users to opt out, as well?
cc @jcemer-stripe @stephenmcgruer
The text was updated successfully, but these errors were encountered: