Trap versus embedder-specific error

[jfbastien]

Over in WebAssembly/spec#483 (comment) @rossberg-chromium and I discuss what should generate a trap versus an embedder-specific error.

AFAICT we currently generate traps for corner-cases of specific opcodes:

• Out-of-bounds accesses
• Invalid input operands for an arithmetic or conversions operation
• Signature mismatch
• Unreachable

We allow generating embedder-specific errors when:

• A trap is generated
• Validation fails
• Compilation fails
• Linking fails
• An arbitrary limit is reached in the static binary
• An arbitrary limit is reached at runtime (such as stack overflow)

@rossberg-chromium's proposed text is:

If the runtime limits of an implementation are exceeded during execution of a computation, then it may terminate that computation by causing a trap or reporting an embedder-specific error to the invoking code.

Generating one or the other seems wrong to me: from my understanding of our design traps don't really fit that purpose.

So what's our approach to traps versus embedder-specific errors? We don't really have a clear approach.

[RyanLamansky]

Doesn't a trap lead to an embedder-specific error anyway?

This becomes more interesting when WebAssembly gets something to cover try/catch functionality. Some currently-fatal errors like stack overflow become survivable.

[rossberg]

Yes, to clarify: Wasm cannot currently distinguish traps from other errors. Any such distinction is completely up to the API. The spec draft for now mirrors that: there is only "traps", and the above formulation merely (ab)uses the term "trap" as a generic means to express abortion of a running Wasm computation (since it's currently the only way to express that), leaving further details of its interpretation to the API spec.

But I see how this may be misleading. The core spec should probably make a distinction somehow (essentially, by introducing a notion of "host error"), for the sake of easier API specification as well as possible future extensions for handling traps inside Wasm.

[sunfishcode]

The resolution here was that the "causing a trap" option was removed.

The normative documentation is here, where it says "If the limits of an implementation are exceeded for a given module, then the implementation may reject the validation, compilation, or instantiation of that module with an embedder-specific error."