Notating 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.

We found in whatwg/streams#366 that it was much easier to trace potential exception flows if we used "Perform AbstractOp(x)" for nothrow ops, and "Let result be AbstractOp(x); ReturnIfAbrupt(result)" or similar for throwing ops. The ES spec uses "Perform" for a similar purpose, although it doesn't define it. I defined it in https://streams.spec.whatwg.org/#conventions

We are considering taking this a step further by notating every abstract op with "nothrow" or "throws" badges: whatwg/streams#371 I think it would be ideal if Ecmarkup supported this, e.g. <h1 aoid="..." nothrow>...</h1>.

The actual project of going through the entire ES spec and updating them with such notations would be ... work. But I think it could be very valuable, and helped along by work such as that @anba has done in the past. On top of such notations, you could even build automated checker tools to enforce the contagion rules, or to enforce the use of ReturnIfAbrupt.

WDYT?

[jmdyck]

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]

Going to close this. We can discuss notational conventions on the ecma262 repo now.