Update JS API to better specify opaqueData exception identity

[dschuff]

[Ms2ger]

3. The mapping between the JS value and the Wasm extern address representing the exception's payload inside Wasm is what's stored in the map.

As far as I understand, there is no Wasm extern address representing the exception's payload.

[rossberg]

@Ms2ger, well, that's exactly what I'm suggesting, though: by exposing it as an externref, we'd naturally assign it such an address, and nothing else would be needed (AFAICS).

[dschuff]

Regarding your numbered points 1-4 about the JS tag: This is not the behavior that the current spec has (or that engines currently implement) e.g. currently we specify that the JS tag has an empty payload and can't be imported. But I actually agree that this behavior makes sense and is what we want (Heejin and I have actually been discussing adding a solution like this in response to user requests to allow the JS value to be obtained inside wasm just as you mentioned). So we should add that.

However, it's not actually what this change is trying to accomplish; this change is trying to accomplish your second question, of whether we should guarantee that a wasm exception maintains its JS-side identity. The answer there is yes, we should, and the implementations currently shipping in web engines do. (Heejin also recently added a test similar to your example). This is because Error objects thrown from JS and WebAssembly.Exception objects created in JS (as emscripten does here) need to preserve their properties (especially their attached stack traces) as they propagate through wasm frames all the way out to outermost try/catch blocks or onerror handlers. (This use case doesn't strictly require that the objects be === but it does require that the properties are the same). Many users obviously depend on being able collect these stack traces regardless of whether they propagate through wasm frames after being thrown, or whether they originate from JS or emscripten code.

I agree that it is not easy to specify! That's why the existing opaqueData situation and this proposed amendment are so complicated and hand-wavy! But it's a very important property to have. And, it's apparently not difficult to implement. The first JS implementations actually had this identity property even before the spec said that they should.

[aheejin]

Is this still relevant? If not, can we close this?

[dschuff]

Is this still relevant? If not, can we close this?

It's not relevant for shipping exnref to phase4. We do still have the appendix with the "legacy" format. I haven't looked at it yet and don't know whether it also includes anything about the JS API but I was thinking it might still be worthwhile to say something about how it should work, since browsers will be the most likely engines to have support for it in the medium/long term. At the very least we should probably still have the legacy tests somewhere.