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