Annotations for what may throw

[littledan]

Should add [Throws] to WebIDL? This is a Mozilla-specific extended attribute which indicates which operations may throw. @fitzgen commented to me that this is very useful for web-sys, the wasm-bindgen component which Rust WebAssembly uses to call WebIDL APIs.

[domenic]

In general I am -1 on Web IDL that duplicates normative prose, and has to be synchronized with it.

[bzbarsky]

There's another problem here. There are various situations (e.g. out of memory or any other resource constraint) that allow any method call to throw at any point and are not really standardized other than being allowed to exist. Whether they can actually throw is implementation-specific. For example, in Gecko, allocating a DOM node can't throw, but allocating a Promise can. And the JIT use cases for [Throws] in Gecko need to actually know when things might throw including these non-spec situations, because we optimize out the "did it throw?" check when the method can't throw.

So standardizing [Throws] would be a bit complicated: it would need to either be set on things where any browser might end up throwing (which is subject to change at any time) or browser IDL would need to not match the spec in various cases.

As for the bindgen use case, what semantics do they want in these non-specced-throw situations?

[littledan]

I believe they would want something conservative, including the attribute on what might throw in any browser.

[annevk]

I'm somewhat in favor as we also document return types as such. I don't think the duplication has been problematic there.

I do wonder though that if we do this, should we also document which promises can reject?

[annevk]

(As for OOM, I'm somewhat hopeful that can we can specify it to some extent some day. Mark Miller seemed to have those ambitions, but probably not the time.)

[fitzgen]

^{+cc @alexcrichton}

@domenic:

In general I am -1 on Web IDL that duplicates normative prose, and has to be synchronized with it.

The problem is that prose is not machine readable, while Web IDL is, so if the error-throwing-ness of an API is going to be documented anywhere, it seems better if it is in a machine readable form. The reason [Throws] would be useful to us (the rust+wasm working group) is for the web-sys crate which is programmatically generated from Web IDL.

@bzbarsky:

There's another problem here. There are various situations (e.g. out of memory or any other resource constraint) that allow any method call to throw at any point and are not really standardized other than being allowed to exist. Whether they can actually throw is implementation-specific.

Yep. We use this information on a best effort basis. We are aware that technically any interaction with JS can throw. It is fine for us to essentially abort on OOM. I think it would be useful to have an attribute for if the spec ever requires that an exception is thrown in certain cases (rather than if it may throw, which is always true).

---

Overall, this isn't super high priority for us because when wasm gets unwinding, we can use that for most everything.

[dontcallmedom]

A recent analysis shows that the lack of a [Throws] extended attribute is the main blocker in rustwasm being able to automatically import WebIDL fragments from web specs at this stage.

[annevk]

It would be good if it would give a concrete benefit specification-wise that was more than an assertion about the algorithm. However, given that we have assertions, perhaps that can be considered sufficient? We could call it [AssertCanThrow].

(I think return values have a concrete benefit in that they can help with converting specification concepts to JavaScript types. This isn't really defined at the moment, but that is how they are used, especially with IDL sequences, but also other types such as Infra strings.)

[Liamolucko]

It would be good if it would give a concrete benefit specification-wise that was more than an assertion about the algorithm. However, given that we have assertions, perhaps that can be considered sufficient? We could call it [AssertCanThrow].

Yeah, that would work.