Interaction with host environments

[kmiller68]

It doesn't look like the current spec describes the interaction with host environments. We should, at least for JS, specify how the exception handling spec is intended to interface with a host's native exceptions, if the host has any. In the JS case, what object is given to the JS catch block?

Also, what do exported exceptions look like to the host environment. Presumably for JS they must be some kind of object, with some internal data associated with them.

One idea would be for for each exception "be" an ES6 like subclass of WebAssembly.RuntimeError. Then if you catch one of these in JS it's indexed properties would be the payload. It also seems like it should have a signature and length as well.

Although, there might be some encapsulation concerns with the above proposal w.r.t non-exported exceptions. Perhaps you should only be able to access the payload if you have the exported exception, which we could do by hiding the data under a Symbol only exposed on the export object.

[KarlSchimpf]

Good point. I will add another section outlining ideas on this. Withing WebAssembly I intentionally left exceptions opaque to limit the assumption on the environment it runs in. However, when running in JS, we can be more explicit and define a JS exception class to implement WebAssembly's exceptions.

[eholk]

It seems like there might be some value in making program-generated exceptions different from errors we've currently defined in the spec. Would it make sense to add WebAssembly.ProgramException or WebAssembly.UserException alongside WebAssembly.RuntimeError?

[eholk]

Another issue we need to hash out is whether hosts can inspect values associated with Wasm exceptions. In the case of JavaScript, how should we represent i64s that are thrown with an exception?

[binji]

In the case of JavaScript, how should we represent i64s that are thrown with an exception?

One solution would be to throw if you try to access those values, but otherwise allow the exception to propagate normally. This would be convenient if say you had a call stack like:

0. TOP
1. Wasm (throws)
2. JS (catch)
3. Wasm (catch)

Then the JS handler could just rethrow the exception for the handler 3 to catch.

[KarlSchimpf]

In my experimental implementation of this in v8, I am handling this issue by writing the exception values thrown into a (JS) typed array of 16-bit values. This allows the encoding of I64 by using 4 16-bit values to hold the I64.

[lars-t-hansen]

In not too long it will feel natural to represent the I64 as a JS BigInt: https://github.com/tc39/proposal-bigint, which is stage 3 (and some implementations are pending). My money would be on this making it into ES 2018. Whatever we do we should try to avoid a situation that prevents BigInt from being used later.

[kmiller68]

I think I agree with @lars-t-hansen here. I expect that BigInt will exist in some form in browsers before exceptions in Wasm are in those browsers. It makes the most sense to pass I64s as BigInts to me. I'm ok with using some other representation for experimentation while we wait on BigInt implementations, however.

[eholk]

Given that we have the precedent of not being able to call functions with i64 in their signature from JS, I think it makes sense to do a similar restriction for exceptions. Then once we have BigInt support we can relax the restriction for both function calls and exceptions at the same time.

[eholk]

Another question we should deal with is whether you can construct Wasm exceptions from JavaScript. I imagine most JS exceptions won't be inspectable to Wasm, but instead fall under a catch_all clause. Perhaps we could do something like this to create Wasm exceptions from JS:

let instance = ...;

let e = new instance.exports.ExportedException(arg1, arg2, arg3);
throw e;

Or maybe something like:

let e = new WebAssembly.ProgramException;
e.tag = instance.exports.ExportedException;
e.values = [arg1, arg2, arg3];
throw e;

The first one looks better to me, since it seems to make it easier to make well-formed Wasm exceptions.

[jfbastien]

Given that we have the precedent of not being able to call functions with i64 in their signature from JS, I think it makes sense to do a similar restriction for exceptions. Then once we have BigInt support we can relax the restriction for both function calls and exceptions at the same time.

Waiting for BigInt is the main reason for this restriction.