configureAll: what kind of error to throw?

[jakobkummerow]

First off, I don't think this is a particularly interesting or important question, but we'll have to make some decision, and if posterity wonders how that decision came to be, I figured we might as well have an issue they can unearth to satisfy their curiosity.

What should happen when the instructions provided to configureAll cannot be performed? There are several possible failure reasons:

• the data array cannot be decoded according to the specified grammar.
• there aren't enough prototypes or functions in the respective array.
• (should we also error when there are too many prototypes or functions being provided?)
• a provided prototype isn't a legal prototype (per JS requirements, e.g. a primitive).
• a provided prototype already has conflicting properties on it, preventing method installation (e.g. a non-configurable property).
• setting a parent prototype fails (e.g. because it would create a cycle, or the child's prototype is immutable).
• the constructors object isn't an object. (Which should probably be allowed if no constructor functions are installed on it?)
• the constructors object already has conflicting properties on it, or was sealed/frozen, etc.

Some of these are more JavaScript-related (e.g. prototype rules) and some are more Wasm-related (e.g. "not enough prototypes" is equivalent to an array.get attempting to read out of bounds).
Should they all throw the same kind of error, and if so, which?
Should they throw a "wild mix" of errors depending on what exactly went wrong?
Should the errors they throw be catchable by Wasm (like JS exceptions are) or uncatchable (like Wasm traps are), or again a "wild mix"?
Should some things just fail silently, like JavaScript would in non-strict functions? (Strict JS functions throw.)

Presumably none of these cases will happen "in practice" assuming a correctly working toolchain has produced the Wasm module.
Also, I don't think any of this has significant impact on performance.
Considering the lack of impact, personally I'm not interested in spending much time on these questions; I just want an unambiguous spec.
If you have thoughts, please speak up, especially if your thoughts are stronger than bikeshed color preferences :-)

Precedent: the JS String Builtins perform tighter type checks than the "default" equivalent JS operations would, and they throw wasm-uncatchable (trap-like) exceptions; both of this was decided because it allows faster inline code sequences to be generated for them, which isn't a concern for configureAll.

(The current prototype in V8 goes the "wild mix" route because that was easiest to hack up; but it's not difficult to change and I don't mind changing it to whatever the spec ends up deciding.)

[tlively]

I propose that as a guiding principle we try to match the errors that a straightforward polyfill running in strict mode would produce.

Specifically:

1. Null input arrays or out-of-bounds reads from the arrays cause Wasm traps
2. Writing a primitive as a prototype throws a catchable JS TypeError
3. Extending a non-extensible object or writing a non-writable property throws a catchable JS TypeError.
4. Malformed data, including invalid UTF-8 in names, will cause a Wasm trap.

In all cases, all mutations up to the point of failure should remain visible.

cc @rmahdav

[rmahdav]

Between having a 'wild mix' of errors and 'throwing the same error', the 'wild mix' route seems the most helpful for debugging. Throwing TypeError when extending a non-extensible object and Wasm traps for null pointer arrays (as examples) make sense to me.

[tlively]

I followed the scheme proposed above in #87. @jakobkummerow has a patch that updates V8 accordingly.