Throwing DOMExceptions in the context of a promise returning operation

[marcoscaceres]

(little bit of a rehash of #214)

As part of feedback for this Screen Orientation spec pull request:
https://github.com/w3c/screen-orientation/pull/251/files#r1180457386

There is a promise-returning operation (.lock()). In that context,@annevk correctly pointed out that I could simply write something like:

• If condition, [=exception/throw=] a newly created "WhateverError" {{DOMException}}.

And have the IDL binding layer do the right thing, as it knows that the operation returns a promise.

However, the definition of throw doesn't make it obviously clear to the reader, who may not know WebIDL very well, that the binding layer will automatically handle the "throw" as a promise rejection.

I wonder if it might be helpful to write a note to describe this behavior and some examples? I've personally experienced issues with spec reviewers being confused if an operation is actually going to throw an exception and not return a rejected promise (just due to this behavior being a bit "magical").

At the same time, it is nice that we have the very clear "return a promise rejected with" to fall back on.

[domenic]

Personally I think it's bad to rely on this conversion as it makes the algorithm confusing for readers. I discourage it in specs I review.

[annevk]

If we don't want this we should make throw hit an assert.