Notate abstract ops that can and cannot throw

[domenic]

In streams, which is heavily promise-based, there are a lot of abstract operations that cannot throw. The ES spec has these too, in smaller number.

Of course, this kind of nothrow vs. throw characteristic can be contagious. If you only use nothrow abstract ops in your abstract op, then your abstract op is nothrow. Whereas if you use any throwing ops, you are now throwing. Unless you are certain for external reasons that the given throw operation will not throw in this context, in which case you might want to assert that it is a non-abrupt-completion.

There are a couple action items here, some of which can be done independently:

• Come up with a convention for asserting that the return value is never an abrupt completion, e.g. Let _result_ be ! AbstractOp(). Use it throughout. A lot of places in the spec currently use "perform" for this purpose, which is not defined anywhere.
• Introduce EMU support for notating with throws/nothrow. (Or perhaps, abrupt/noabrupt.) You can see this in action in Streams, e.g. https://streams.spec.whatwg.org/#rs-abstract-ops. For the source format, I'd suggest either <emu-clause nothrow> or <emu-clause flair="nothrow">.
• Go through the ES spec and update all abstract ops with whether or not they can throw. This could be done incrementally.
• Build automated checker tools to enforce the contagion rules, based on throw/nothrow and ! or ?.

[ljharb]

What about the case where the result of AbstractOp is not needed? That's usually the cases where "Perform" appears. Having a useless _result_ doesn't seem ideal. Do you have an alternative suggestion for an abstract op that solely causes side effects (some of which can throw, and some of which can't)?

In general I love this idea - being explicit about what can throw and what can't seems like an overall improvement.

[domenic]

Do you have an alternative suggestion for an abstract op that solely causes side effects (some of which can throw, and some of which can't)?

1. ? AbstractOp() to bubble errors, or 1. ! AbstractOp() to assert it never errors. You could introduce the "perform" verb for that but I'd like it to be defined this time.

[ljharb]

Sounds good - I like having an explicit "this is for side effects" mechanism like "Perform".

[jmdyck]

Here's what I said when this was raised in the ecmarkup repo:

Presumably "Perform AbstractOp(x)" implies not just that AbstractOp doesn't throw, but also that it doesn't return anything useful (via normal completion). (Or at least, that these things are known to be true for the particular arguments being passed.)

I think it would be ideal if Ecmarkup supported this, e.g. <h1 aoid="..." nothrow>...</h1>.

To generalize your suggestion, I think it would be useful (though even more work) if every operation had a "header" that systematically listed/described the operation's inputs (parameters) and outputs (returns). (Currently, preambles give some of this info, but not consistently or completely.) E.g., outputs/returns might say something like:

normal returns: Boolean
abrupt returns: TypeError

So the throw/nothrow distinction would be captured by whether any abrupt returns are listed.

[bterlson]

@jmdyck: that would be amazing, but much work... I think we can probably get there eventually by going down the path of incrementally adding !.

Note that Perform X() is not about implying that AbstractOp doesn't throw (note further the many instances of Perform ? Op()). It's simply ecmaspeak for "the result of X()" where x doesn't have a useful result. In other words, with bang, if an abstract op doesn't have a useful result, we'd want Perform ! Op().

I fully support ! as a short-hand for "Assert: previous thing is not an abrupt completion". We can probably just start the incremental addition by doing a similar regexp replace as we did to kick off the ? conversion.

[zenparsing]

I'm a little worried about extending the ECMASpeak programming language too fast. The RIA shorthand was a good buy in terms of readability/writability, but I'm not so sure about "!".

[jmdyck]

@jmdyck: that would be amazing, but much work...

I'm prepared to do the work if we can agree on a "header" syntax.

[domenic]

I'm a fan of !. It fixes two important problems with the current spec:

• There are many cases where a completion value v is used, but v.[[value]] is expected. For example, CreateDataProperty(array, ToString(n), e). ToString returns a completion value, but CreateDataProperty does not accept completion values as its second argument. This is just a bug in the current spec really. (Or if you prefer, an intentional type mismatch for the sake of brevity.)
• There are several (39) places in the spec where we assert something is not an abrupt completion. This is a bit distracting, but is honestly probably something we should be doing more! It should be easy to say something is expected to never throw.

I am less of a fan of the header syntax, but some mock-up screenshots could possibly convince me.

[anba]

ToString returns a completion value, but CreateDataProperty does not accept completion values as its second argument. This is just a bug in the current spec really. (Or if you prefer, an intentional type mismatch for the sake of brevity.)

No, it is a specified and documented feature of completion records to allow implicit access to the [[value]] field (cf. 6.2.2.2).

How about doing it the other way around: Explicitly state with ! when a caller needs to receive a completion record. I think that should be more ergonomic than adding ! after every infallible operation.

[rossberg]

@anba, please no. The spec should not be optimised for maximum brevity but for maximum clarity. I think the implicit conversion from completion records to their values is actively harmful in that regard. There are already too many hidden conventions going on in the spec (a criticism I keep hearing from fellow V8 implementers trying to make sense of it every other day).

[domenic]

No, it is a specified and documented feature of completion records to allow implicit access to the [[value]] field (cf. 6.2.2.2).

Yes, that is what I meant in the parenthetical.

[jmdyck]

I think the implicit conversion from completion records to their values is actively harmful in that regard.

I agree. (And also the reverse implicit conversion.)

I've thought of an approach that I think would eliminate most of these conversions. I'll raise it in another issue when I have some time.

[allenwb]

I want to support the general position expressed by @rossberg-chromium above.

Maximizing clarity (and particularly for occasional readers should be among the highest priorities. Most readers of the spec. are not spending 8 hours a day emerged within it. More likely they are occasionally looking up some specific details. They may or may not have read the clause 5 conversions and even if they have they may not remember them what they read.

@domenic things like CreateDataProperty(array, ToString(n), e) is used in situations where n is known to have a value that will convert to a string, without error. Most typically this is an integer valued index variable of a algorithmic loop. I considered making the conversion from completion to value explicit but found that formulation to be less readable.

[bterlson]

Going to close this issue as I believe we have satisfied the original request.

[domenic]

I don't believe we have. The first bullet point is mostly implemented, but the overall request motivating it (as outlined in the subsequent ones) remains open.

[bterlson]

Oh I see, sorry about that.

[domenic]

Is this really fixed?

[ljharb]

The only abstract operations that can throw now return a completion record; those that can't, don't. It's possible it's not being noted in the rendering just yet? cc @bakkot @michaelficarra to confirm

[domenic]

I think I see. Wow, that is really unfortunate, for the reasons I argued long ago in #486 (comment) and elsewhere. I wonder how many places in HTML/Web IDL will need updating to remove the ! prefix they've been using. Oh well.

I'll note that it seems like this idea doesn't hold for abstract/internal methods, e.g. https://tc39.es/ecma262/#sec-ordinary-object-internal-methods-and-internal-slots-getprototypeof returns a completion but cannot throw, and similarly for https://tc39.es/ecma262/#sec-declarative-environment-records-hasbinding-n . But I can understand why that would happen.

[ljharb]

It's true that for internal method overloads where some of them throw, the ones that don't still need to return a completion.

[bakkot]

@domenic re

Eliminating the ! from the call site reduces clarity, making me jump to the definition of the abstract operation to find out if we're assuming it returns a non-completion record, or a completion record.

We've adopted the convention (enforced by tooling) that every call of an operation which returns a completion record is of the form ? A(), ! A(), or Completion(A()), and no call of an operation which does not return a completion record is of that form. So you don't have to jump to the definition to know if an operation can throw; that information is present at every call site.

(The Completion form is rare; it only comes up when explicitly manipulating completion records, usually for promises or iterators.)

[syg]

I wonder how many places in HTML/Web IDL will need updating to remove the ! prefix they've been using.

Does HTML / WebIDL call many AOs that don't actually return completions? My intuition would be that it doesn't actually, so relatively few sites would need changing.

Edit: Upon looking in HTML the answer is actually yes, because there are several calls to predicates that now just return a boolean. I can prepare a PR for that.

[domenic]

Just skimming https://webidl.spec.whatwg.org/#index-defined-elsewhere: MakeBasicObject, CanonicalNumericIndexString, GetFunctionRealm, IsConstructor, ... I'd guess maybe 1/4 of all abstract ops?

[bakkot]

Once the updated ecma262 biblio is published (for the first time since 2016...) it would probably be pretty easy to check those with tooling.

I note that ! isn't currently used consistently in HTML specs. In some cases, for example the call to OrdinaryGetOwnProperty in step 2.1.2 of CrossOriginGetOwnPropertyDescriptor; that's because the operation actually doesn't throw. In others, for example the call to GetFunctionRealm in step 9.a of HTML element constructors; it's not clear to me if it actually can throw in that position and the authors failed to account for it, or if there's some reason it definitely can't in this case. (Did you know GetFunctionRealm can throw? Fun fact! Revoked proxies are fun!)

In an ideal world, tooling would do the same checks ecma262 does, so that authors actually have to deal with possible exceptions for operations which can sometimes throw.

That's the main reason we did it this way: rather than just sprinkling ! on every call, you can skip it for AOs which can never throw, and for those which sometimes throw you have to actually think about that particular call site.