New error name: OptOutError

[rsolomakhin]

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

[bathos]

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.

[rsolomakhin]

Not familiar with AbortSignals. Could you provide reference or example, please?

[stephenmcgruer]

@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 🤣

[bathos]

Not familiar with AbortSignals. Could you provide reference or example, please?

AbortController & AbortSignal are the web platform’s generic cancellation primitives. Some examples of their use in other specs:

• Eyedropper
• Fetch
• Geolocation Sensor
• Scheduler
• Web Locks
• WebAuthn
• (maybe ~9 others, only went through the first few pages of matches)

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.

rather than a browser operation to tell the website that it has or is aborting

AFAIK several of these, like WebAuthn, use them this way (e.g. user bailed from mediation UI).

[domenic]

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,

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.

and if we've put in any thought to whether DOMExceptions could carry more structured data to allow for better error handling by developers.

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:

• Spec authors would need to subclass DOMException.
• Spec authors would need to define serialization/deserialization steps for their subclass. Maybe this could be made more ergonomic by providing some infrastructure in Web IDL.
• https://webidl.spec.whatwg.org/#idl-exceptions will need some updating, e.g. change "eb IDL does not allow exceptions to be defined", and update various things that talk very specifically about DOMExceptions to also mention their subclasses.
• https://webidl.spec.whatwg.org/#es-creating-throwing-exceptions will need some updating to handle subclasses and come up with conventions for throwing them.
• Web IDL should provide some guidance for how to do this, especially e.g. on constructor signatures, and the interaction with the base class name field and argument.

[nickburris]

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 SPCOptOutError, or would it make more sense to add a general OptOutError to the error names table? Our use case is pretty straightforward, I believe the idl would just look like:

interface SPCOptOutError : DOMException {
};

since we don't need any special attributes.

[annevk]

If you don't need anything special, extend the error names table. No need to add another global for that.