[js-api] Should rethrow/br_on_exn trap on undefined?

[aheejin]

We decided to make rethrow and br_on_exn trap on a null value in #90. Should we do the same when a given exnref is an undefined value thrown from JavaScript?

Raised by @backes in https://bugs.chromium.org/p/v8/issues/detail?id=10128#c12.

[RossTate]

I think wasm programs should be able to expect that they can rethrow any exnref that was caught by a try-catch.

[RossTate]

Oh shoot, apparently that's already not the case. From what I can tell of the JS API in #86, which lines up with the linked Chromium issue, if JavaScript throws null then the exnref caught by a surrounding try-catch in wasm will be ref.null.

[aheejin]

This is not about null but about undefined I think? And #86 does not seem to say anything about neither null nor undefined case. (And #86 was written before we decided on #93, so it needs revision too, but it's not relevant with this issue)

[RossTate]

I was trying to figure out what the interaction of wasm exception handling and JS throws was in more detail so that I could understand the problem more, and #86 was the most recent description I could find. In particular, it says that a JS value being thrown is converted to a wasm value via ToWebAssemblyValue. I then noticed that ToWebAssemblyValue converts a JS null to ref.null, hence the follow-up comment above. (It looks like #93 doesn't change that observation.)

So I don't know what to do about my first comment. It seems like a useful principle to always be able to assume you can rethrow an exception you caught. But I didn't realize at the time that the principle is incompatible with the existing design, so I'm at a loss for suggestions. My original thinking was that the semantics of rethrow and br_on_exn should be independent of what JS value was thrown, but it already depends on whether the JS value was null or not, so I'm not sure what general principle to apply. Sorry for my thinking out loud.

[RossTate]

Hmm, I realized that the JS-interop strategy here has the ability to turn any wasm reference into an exnref. First, give the wasm reference to JS code so that it goes through ToJSValue, then throw the resulting reference in JS code. When this exception enters a wasm stack frame, it will go through ToWebAssemblyValue, which is nearly the inverse of ToJSValue. Then wasm code can catch that value as an exnref.

To make this concrete, the following module instantiated with the subsequent JS importObj uses this trick to turn a funcref into an exnref. It then uses a similar trick to turn that exnref back into a funcref so that it can be called. Thus the following is a very roundabout way to call $foo with the argument 5.

(module
    (import "js" "throw_funcref" (func $throw_funcref (param funcref)))
    (import "js" "exnref_to_funcref" (func $exnref_to_funcref (param exnref) (result funcref)))
    (func $call_indirect_i32 (param funcref i32) ...) ;; uses a funcref table and call_indirect to call the given funcref with the given i32 as its argument
    (func $foo (param i32) ...)
    (func $main
        (try
            (call $throw_funcref (ref.func $foo))
        catch
            (call $exnref_to_funcref)
            (i32.const 5)
            (call $call_indirect_i32)
        )
    )
    (start $main)
)

var importObj = {js: {
    throw_funcref: (ref) => throw ref,
    exnref_to_funcref: (ref) => return ref // intended to trap when ref is not funcref
}};

I'm guessing this behavior was not intended? In particular, it seems to imply that is_exnref would have to always return true if it were ever added.

[backes]

Since catch is specified to catch any host exception, and JS can throw any reference, we have to assume that exnref could hold arbitrary host references.
What we need to clarify here is what Wasm can do with these references. I agree with Ross that Wasm should generally be able to rethrow them. If it's a wasm exception, then of course br_on_exn also needs to work. Apart from that, we should probably handle them as opaque references (meaning they don't trap if you br_on_exn or rethrow them).

null seems to be the only special case we need to think about, since this is a value that can be produced from Wasm.

I don't really see how this discussion relates to function references though. Ross' example assumes that funcref can be passed to the host (JS in this case), which means that ToJSValue provides a host reference to the respective funcref, and ToWebAssemblyValue converts back to funcref. This is independent of exception handling, and should be discussed in the reference types proposal.

[RossTate]

The use of function references in my example is just to make things concrete (and its JS API is in the reference types proposal, which I don't think anyone wants to change). The point of my example is that, with the current JS API for exceptions, an exnref can be an arbitrary wasm reference, not just host reference.

The issue I'm pointing out, the issue raised with "undefined", and the existing issue with null are all related because they all have to do with how wasm/JS values are coerced as the cross the wasm/JS boundaries.

[RossTate]

It occurs to me that when C++ programs throw an exception in wasm, they have to specify an event mark, e.g. __cpp_exception, and the exnref is the event mark paired with the payload. Similarly, the above issues would all be addressed by having JS exceptions be some (abstract, universal) event mark, e.g. __js_exception, paired with a (possibly null) JS-reference payload.

[aheejin]

@backes According to ToWebAssemblyValue and ToJSValue in reference types JS API spec, when funcref goes from wasm to JS, it becomes an ExportedFunction, and when an ExportedFunction goes from JS to wasm, it becomes funcref.

Then when a JS function throws an ExportedFunction object (which might have been originally funcref and became ExportedFunction via ToJSValue), does it become funcref again? But it should be an exnref to be caught. Is that exnref that has funcref in it? Or is that exnref that has some JS object (ExportedFunction) in it?

[rossberg]

I think some of the recent comments are based on domain errors. An exnref is not the value caught, it contains the value caught! Throwing null from JS still materialises as a non-null exnref when caught in Wasm. That contains some abstract host value, which happens to be the JS null value (though there is no way to observe that). That is unrelated to null exnrefs, which are merely uninitialised exnrefs.

Similarly if you throw an exported function.

ToJSValue and inverse do not even enter the picture.

[RossTate]

Ah, so it sounds like you had in mind something in line with what I was suggesting with making throwing JS exceptions analogous to throwing C++ exceptions.

But I think it's oversimplifying to say ToJSValue and ToWebAssemblyValue do not enter the picture. One has to consider what should happen if a caught-in-wasm wasm-thrown exception exits to JS as an exnref or anyref and then is thrown by JS code, and similarly if the exception was JS-thrown. From the intuition you suggest, if JS code throws a value v, wasm catches it as an exnref, then the exnref gets passed back to JS and JS throws that value e, then e and v should be distinct values. In particular, e should be an exnref-wrapping of v. On the other hand, if wasm catches the JS-thrown value v and then rethrows it, and then JS code catches that as e, then e and v should be the same value. So this means ToJSValue (or the concept thereof) works differently on values exiting wasm through normal means versus values exiting by being thrown, since in the former case exnrefs are left untouched whereas in the latter case they are unwrapped. That's not necessarily a problem; I am just pointing out that wasm-to-JS and JS-to-wasm conversions are very much part of the picture.

[rossberg]

What you're saying boils down to the question what ToJSValue does for exnref values passed back to JS normally. If that were to coerce exnref values to their contained value then that would be an explicit unwrapping that could not be reverted by ToWAValue. That is, passing the value back to JS would not give you an equivalent exnref. That's probably undesirable.

From the intuition you suggest, if JS code throws a value v, wasm catches it as an exnref, then the exnref gets passed back to JS and JS throws that value e, then e and v should be distinct values.

Fair point, but I think separable. We could still define special behaviour when catching an exnref thrown from JS (because JS itself cannot create such values). Whether that's necessary I'm not sure.

A better alternative might be to provide a special throw method in the JS API for throwing a proper Wasm exception.

In practice, I don't see much of a use case for passing exnrefs to JS, and I'm not sure it should be encouraged.

[RossTate]

If that were to coerce exnref values to their contained value then that would be an explicit unwrapping that could not be reverted by ToWAValue.

Oh, to clarify. I meant to say that specifically JS-values-wrapped-as-exnrefs should be unwrapped when thrown from wasm to JS, not arbitrary exnrefs.

That is, passing the value back to JS would not give you an equivalent exnref.

Even give the above clarification, this point of yours suggests that exnref should not be equatable.

In practice, I don't see much of a use case for passing exnrefs to JS, and I'm not sure it should be encouraged.

Nonetheless, it is possible to do and so needs to be specified. And, being a web standard, we cannot really change this specification later on. This means we have to try to anticipate all of the ways it could be practical now and design for those patterns.

[aheejin]

Thank you for the clarification. So let me check a few more points:

• When exnref is rethrown to JS, it is unwrapped, but it is passed to JS by a function argument, it stays as is, right? So I guess we need ToJSValue for exnref I guess, because even if it is not a desired usage, it is possible. This will likely to be a new object in JS. Does it make sense?
• What happens exnref that is not created by JS is rethrown to JS? Does it get unwrapped or stays that way?

I guess these are the points we should state in our JS API.

[rossberg]

@aheejin, conceptually, I would say that an exnref is unwrapped at the moment it's rethrown in Wasm (which is why that instruction traps on null), regardless of where it's caught. If caught in Wasm, a new exnref is produced at the catch site. If caught in JS, you either get the JS value contained or some opaque object representing the Wasm exception.

We could define that throwing a Wasm exception on the JS side behaves like a rethrow in Wasm.

Yes, the JS API certainly needs to define something. It'll probably need to define a new form of Wasm exception exotic objects to represent Wasm exceptions on the JS side.