WebAssembly.Exception is not a subclass of JS Error

[kmiller68]

Since WebAssembly.Exception is a JS subclass of JS's Error class it seems like it should be possible to provide the message and cause properties from the constructor. Currently, the WebAssembly.Exception constructor only takes the WebAssembly.Tag and the tag's parameters. Is the inability to provide a message or cause intentional or an oversight?

[eqrion]

I was under the understanding that WebAssembly.Exception was not a subclass of JS's Error class.

[kmiller68]

@eqrion Ah, yeah you're correct. I guess then this should be retitled to should it be a subclass of JS Error? I'd expect developers would want to know the stack from which their exception originated when they get an uncaught exception.

[eqrion]

I believe this was intentional and discussed in some other threads, but it's hard for me to find definitive statements on it. This comment seems relevant. If that's the case and still valid, it may be good to formally state that somewhere.

[kmiller68]

Yeah, I can see the argument for not gathering stack traces eagerly. On the other hand, I'd guess there's a significant number of developers that want those stack traces for diagnostic reasons. Perhaps we should have a way to natively create an exception with a stack trace? I suppose an alternative would be to pass a JS Error object as one of the tag's parameters but that still requires calling to JS.

[thibaudmichaud]

Note that in V8 there is already a way to opt-out of stack trace capture by setting the "Error.stackTraceLimit" property to 0: https://v8.dev/docs/stack-trace-api. This is not standardized though, but if other engines provide a similar functionality I think that's a very strong argument in favor of making wasm exceptions inherit from JS Error. This provides an easy and efficient way to enable/disable stack trace collection for wasm exceptions.

[fgmccabe]

There is a fundamental 'problem' with automatically collecting stack traces for wasm exceptions: the information may be useful in the case of diagnosing an unhandled exception; but many languages have very specific requirements for what stack trace information to collect and these cannot currently be handled in the EH proposal without considerable heavy lifting. (E.g., Java's stack trace is for the entire stack at the point of creating the exception (in terms of methods called), Python lets you control how much of a trace to generate, C# normally records a stack trace when the exception is thrown)
The second main issue is that collecting traces is inherently expensive and doing so would have a chilling effect on using exceptions for control flow purposes.

[aheejin]

@fgmccabe

There is a fundamental 'problem' with automatically collecting stack traces for wasm exceptions: the information may be useful in the case of diagnosing an unhandled exception; but many languages have very specific requirements for what stack trace information to collect and these cannot currently be handled in the EH proposal without considerable heavy lifting. (E.g., Java's stack trace is for the entire stack at the point of creating the exception (in terms of methods called), Python lets you control how much of a trace to generate, C# normally records a stack trace when the exception is thrown)
The second main issue is that collecting traces is inherently expensive and doing so would have a chilling effect on using exceptions for control flow purposes.

One thing I'd like to make clear is that the current spec doesn't mandate stack traces generation now. So the current problem is more about figuring out how we are going to get stack traces and not how we make the engine faster in face of generating the stack traces.

Also I don't think we can standardize the stack trace format from our JS API. By the way I just found out even Error.stack itself is not a standardized thing... V8 and FF implement it but apparently it's not a standardized property.

[aheejin]

While I don't think we should mandate stack trace generation, there are several levels to it. Higher number means less mandatory.

1. We mandate stack trace generation for all engines. I don't think anyone is arguing for this.

2. We mandate stack trace generation in JS API, making WebAssembly.Exception inherit from JS Error. This will only affect web VMs.

3-a. We make WebAssembly.Exception inherit from JS Error, but as @thibaudmichaud pointed out, that may not mean we should generate stack traces. So stack trace generation is optional. (But as he said if it's not a standard feature, can we make our spec rely on that?)
3-b. We make WebAssembly.Exception take a boolean saying whether to generate stack traces or not. Depending on this parameter, the web VM can decide whether to use JS Error or not.
3-c. We don't say anything about JS Error in JS API, but each toolchain can devise its own way to generate stacktraces. For example, instead of a toolchain generating wasm throw instruction, create a JS function that throws JS Error and import it from wasm and use it. (Not sure if it's ideal, but listing it here just to be exhaustive.)

(The formatting here seems messed up, sorry, not sure how to fix)

Searching the repo for previous discussions, I found #150 (comment). @takikawa @rossberg Any opinions on this?
Also cc @Ms2ger who worked much on JS API.

[dschuff]

At a high level I really would like to be able to support both the use case of getting diagnostic info from uncaught (or not-immediately-caught) exceptions (which as @kmiller68 mentioned, includes messages as well as stack traces) and also the use case of using EH for control flow which would be harmed by taking stack traces on every throw. IMO that means there should be some way 1) to throw from wasm without any stack trace or message generation, and also 2) to have an Error-shaped object propagate out from C++-style exceptions. Ideally the content of that object matches what web users would expect; i.e. it would be the same as what web engines already generate by default from JS exceptions (even if that content isn't fully specified). Note also that the latter use case is scoped to JS.

I think that for Emscripten it would actually be OK to to call out to JS code to throw C++ exceptions (i.e. instead of using the wasm throw instruction directly). Making it throw JS Error instead of WebAssembly.Exception (which I think is the intent of 3-c) would be problematic however, because then C++ exceptions would be indistinguishable from JS exceptions originating from user JS code (currently emscripten handles C++ exceptions directly but just runs destructors when JS or other foreign exceptions propagate).
Adding arguments to the WebAssembly.Exception constructor to allow it to optionally take a message and generate a stack trace seems OK to me in principle. It would mean that these objects might or might not have the fields that would be expected of a JS Error, and any user code that deals with unhandled exceptions would have to be prepared for that. This can happen in JS already (when things other than Errors are thrown), so maybe that's ok. But I don't really know enough about JS API design to know whether that's a good idea.
This also means that in this case there could be an asymmetry between the wasm throw instruction and the JS API. I think I'd prefer to leave the throw instruction as "bare" (it would take no arguments other than the thrown value, and it would not generate messages or traces when used on the web), and make JS users explicitly allocate a WebAssembly.Exception if they want a stack trace. The other option would be to have some kind of way to make a core-wasm throw instruction also generate a message and/or stacktrace, but 1) we wouldn't really have any way in the core spec to say what exactly that info would look like, and 2) there would still be an asymmetry, since on the wasm side the stack trace would be taken on throw and on the JS side it would still be presumably taken on exception object allocation, as it is in JS today.

So all that is to say, tl:dr I like something like option 3-b, with a non-tracing throw instruction.

[aheejin]

I generally agree with what @dschuff said. I think whether WebAssembly.Exception should be a JS Error can be an implementation detail and doesn't have to be specified in the spec, which also means I don't think we need to either mandate or ban it. I also think, as I said in the previous comment, stack traces should not be mandatory.

I propose we choose one of these two options:

1. We make WebAssembly.Exception take a boolean saying whether to generate stack traces or not. Depending on this parameter, the web VM can decide whether to use JS Error or not. Because a bare wasm throw instruction cannot access this option, I think toolchains should provide a way to access this option, i.e., providing a host function that throws WebAssembly.Exception with the stack trace option on.
2. We don't say anything about JS Error in JS API, but each toolchain can devise its own way to generate stack traces. For example, instead of a toolchain generating wasm throw instruction, create a JS function that throws WebAssembly.Exception in JS. The toolchain can insert additional properties to this Exception object to this object before throwing, such as message or stack (stack traces). Also the toolchain can even make its prototype point to JS Error so that it will behave like JS Error. The point is these are implementation details, and we trust toolchains to do this rather than specifying anything in the JS API.

(These are basically some adaptation of 3-b and 3-c in my previous comment.)

Both options would probably need that toolchains provide an option for stack traces, and if it's on, wasm code uses an imported host function (which throws WebAssembly.Exception) when throwing an exception. When it's off, wasm code uses a bare wasm throw. This option can be on or off by default depending on the language and VM. If the language requires fast exceptions this should be off; if not it can be on.

I'd appreciate any opinions on the preference of either of these options. Also if you have another alternative not listed here I'd appreciate that too.

[Ms2ger]

I don't have a strong opinion either way, but I strongly disagree with this:

I think whether WebAssembly.Exception should be a JS Error can be an implementation detail and doesn't have to be specified in the spec

Authors should be able to rely on the same code working across browsers, whether that's with or without subclassing or stack traces.

[RossTate]

Both options would probably need that toolchains provide an option for stack traces, and if it's on, wasm code uses an imported host function (which throws WebAssembly.Exception) when throwing an exception. When it's off, wasm code uses a bare wasm throw.

When the issue of stack traces was discussed long ago, I was told that a key requirement was that tooling not have to differ depending on whether stack traces were enabled or disabled, even if that difference was just a change to what import gets provided to the module (rather than the much more extensive difference suggested above).

If that requirement is no longer in place, then we can consider making stack traces an explicit part of the payload. In the JS API, one can indicate that a specific externref-typed index in the tag's payload provides the stack trace. In the wasm module, one can import a $__get_stack_trace : [] -> [externref] function (which can simply return null when the person instantiating the module wants stack traces to be disabled) and use that to generate the stack trace to put in the payload of the throw instruction.

In addition to giving applications a lot more control over a feature that can have a 6x impact on performance, making stack traces explicit enables us to greatly simplify the proposal. At present, the difference between rethrowing an exception and throwing an exception with the same tag and payload is just the stack trace. So by making this implicit difference explicit, we can eliminate the need for the most complicating aspects of this proposal: rethrow/delegate/catch_all (leaving us with just try/catch/throw).

Those simplifications also make addressing #158 and #185 easy as there are no longer instructions whose placement is severely restricted.

The impact of this change would be minimal on engines because, besides removing instructions, it only affects the JS API. There would be more substantial changes required of tooling, but it sounds such changes likely need to happen anyways.

[aheejin]

@RossTate

1. This issue is discussing a very specific aspect of JS API based on the current core spec, so if you are proposing drastic changes to the current core spec, please do it in a new issue. I will not discuss core spec changes in this issue anymore after this comment.
2. We are aware that you wanted to remove many instructions before, but I think we discussed them for a long time last year already, and decided to settle on the current spec. I'd like to refrain from relitigating all those again given that we are planning to advance to Phase 4 in near future. Also some of the arguments you mentioned, including delegate or Encoding Exceptional CFGs #185, are not even related to stack traces at all. But again, let's not do that in this issue.