JS API for traps

[aheejin]

I proposed not to catch traps with wasm catch instruction in #1 (comment). Even though it has not been decided yet, in this issue I'd like to discuss JS API changes in case we decide not to catch traps as I proposed.

To make this behavior consistent, traps should not be catchable both before and after they hit a JS frame. To this end, it might be convenient if we have JS API to create a WebAssembly trap, like

trap = new WebAssembly.Trap()

So that we can maintain its trap identity in both JS and wasm.

But the current JS API specifies if an exported function call traps, the JS frame that called the exported function should throw a WebAssembly.RuntimeError.

So I'm wondering, should we preserve this behavior? If we should, we may have to make catch not catch RuntimeError exception. RuntimeError contains various error conditions other than traps. I think most cases of RuntimeError are unrecoverable errors, but would there be any case of non-trap RuntimeError that should be caught by catch instruction?

Or, would it be better to create WebAssembly.Trap and change the JS API so that in case of a wasm trap, its embedding JS frame throws not RuntimeError but Trap instead, and catch instruction catches all other JS exceptions except for Trap?

cc @dschuff @mstarzinger @Ms2ger @lukewagner @rossberg
@backes (In case this has implementation issues)

[rossberg]

AFAICT, RuntimeErrors correspond to traps and only traps in Wasm. What other possible conditions are you referring to (except a user manually creating one)? There shouldn't be any need for introducing a new Error class for traps -- and that would break existing code anyway.

So, I believe that filtering RuntimeError from catch is the only backwards compatible way in which we can prevent Wasm from catching traps after an intermediate JS frame.

If we do that, then we probably also want to filter stack overflow and out of memory exceptions, which are implementation dependent, but could originate from Wasm code as well.

[aheejin]

I think you're right... there are many conditions that can cause an error but it looks like traps are the only case that can case an error during func_invoke. Would there be implementation implication to v8? @mstarzinger

As you said, stack overflow and OOM can throw any errors depending on the implementations. What would be a good way to make them not catchable? We can start with some frequent errors (such as RangeError), but I'm not sure if we can prevent all of them from being caught, given that they can be anything.

[dschuff]

Just to be clear, I think @rossberg is saying that the wasm catch instruction shouldn't catch traps or stack overflow or OOM exceptions, which makes sense. For the RangeErrors which arise from e.g. OOMs, I think the engine will have to track internally whether it was originally a wasm OOM or something else, (so that when it unwinds from a wasm frame, through a JS frame, and back into another wasm frame, it can tell the difference).

I think once any of those propagates into a JS frame it would have to be just a regular JS exception though, right? Uncatchable JS exceptions aren't a thing AFAIK, and I guess changing the JS type thrown by a trap would be a breaking change?

[aheejin]

I think once any of those propagates into a JS frame it would have to be just a regular JS exception though, right? Uncatchable JS exceptions aren't a thing AFAIK, and I guess changing the JS type thrown by a trap would be a breaking change?

Yes, given that we can just not catch RuntimeError, I don't think we need to introduce a new Trap type after all, so I think we don't need a breaking change.

[mstarzinger]

I think you're right... there are many conditions that can cause an error but it looks like traps are the only case that can case an error during func_invoke. Would there be implementation implication to v8? @mstarzinger

Yes, it should be doable for V8 to filter RuntimeError objects that represent an error originating from func_invoke during stack unwinding. During unwinding we would make sure that such exceptions cannot be caught by a wasm catch, and hence can only be caught by the embedder (i.e. a JavaScript try {} catch(e) {} statement). This works independently of how many JS frames and wasm frames are interleaved on the stack or in which order they are interleaved.

It is important however to base this distinction between such a RuntimeError exception and any other arbitrary exception on a predicate that is not observable by JavaScript. What I mean by that is we should make sure this distinction is not based on the instanceof operator, because that predicate can be intercepted in JS by setting the @@hasInstance property on RuntimeError. This in turn would make VM internals of how exception handling and stack unwinding is implemented in different VMs observable. Using an internal slot not visible to JavaScript on the other hand should be safe.

Just to be clear, I think @rossberg is saying that the wasm catch instruction shouldn't catch traps or stack overflow or OOM exceptions, which makes sense. For the RangeErrors which arise from e.g. OOMs, I think the engine will have to track internally whether it was originally a wasm OOM or something else, (so that when it unwinds from a wasm frame, through a JS frame, and back into another wasm frame, it can tell the difference).

Good point. The internal slot I mentioned above could also be used to distinguish a e.g. RangeError that originated from within wasm from one that originated from somewhere else.

I think once any of those propagates into a JS frame it would have to be just a regular JS exception though, right? Uncatchable JS exceptions aren't a thing AFAIK, and I guess changing the JS type thrown by a trap would be a breaking change?

Agreed, once any exception propagates into JS it should be represented as a regular JS exception (modulo the internal slot I mentioned above). This should be doable without changing the JS type of any existing exception.