Wasm exception objects and debuggers

[sjrd]

To do some follow-up on #76, specifically about the case of Wasm exception objects and how they behave wrt. debuggers.

In Munich, we discussed this issue IIRC with @lukewagner and @aheejin (if I made the right GitHub handle connections). One possible solution came up that would build on Custom Descriptors: a standardized well-known symbol that redirects to a "real" JS Error instance.

Currently, exception objects like java.lang.Throwable are Wasm objects, so they cannot extend the JS Error class, and do not get stack trace information. However, we make them contain, in a field, a reference to a freshly allocated Error instance. This allows to implement things like Throwable.getStackTrace() by inspecting the underlyingJSError.stack property. So we're not completely clueless: internal language tools, testing frameworks, etc., understand the stack traces.

What we're missing is for debuggers to understand our exception objects. A possible solution would be to use Custom Descriptors to expose the underlying Error instance in a standardized way, which debuggers could access:

• Define a well-known symbol WebAssembly.underlyingError
• Register a get [WebAssembly.underlyingError]() on the JS prototype associated to java.lang.Throwable
• Have its body return the Error instance that we are storing inside our exception objects.

Now, debuggers can use that information. If they hold a thing e that's not an "error object", they can try to look into e[WebAssembly.underlyingError] to get a second chance. They could then offer all the nice debugging infrastructure for Wasm objects, based on that underlying Error instance.

Arguably, such a proposal could go all the way up to TC39 as Symbol.underlyingError rather than WebAssembly.underlyingError.

[mhofman]

This seems a little bit of an inversion to me. Engine debuggers are not the only things inspecting thrown values, and lots of code out there recognizes error instances, and I expect more-so now that we have Error.isError in the language.

I'm not super familiar with the constraints here, but could wasm use the Error instance when crossing the boundary into JS, and reference from that error instance to the wasm opaque object in a cause property? Then at the very least all existing tooling handling errors would keep working, and updated tooling capable of extracting more information from the wasm opaque object would be able to do so through the causal link.

[tlively]

I don't think we would want to make the Wasm/JS boundary more costly to support this use case, and for normal usage there is no need for that; toolchains can emit JS glue code to extract the underlying Error object as necessary. Having a standard way for debuggers to extract richer information wouldn't slow down normal execution, though, and of course normal glue code could also use this mechanism.

@bashor, would you use this?

@pfaffe, do you have any thoughts from the devtools side?

[mhofman]

I personally wouldn't want to muddy the waters even more on what objects should contain error diagnostics in JS. We have Error instances, and are getting objects extended with Error.captureStackTrace (standardized for web reality reasons), and I would prefer to keep it at that.

IMO the glue code should extract (or create) the JS Error instance whenever something meant to be equivalent to an error is thrown on the wasm side.

[tlively]

IMO the glue code should extract (or create) the JS Error instance whenever something meant to be equivalent to an error is thrown on the wasm side.

I see this idea as providing a brightly lit path for doing exactly this. It's not defining a new kind of error, but rather defining a common protocol for extracting a normal Error. If defining a new well-known symbol seems too heavyweight for this purpose, then we could just as well document somewhere that debuggers should try calling some getError or intoError method instead.

[mhofman]

I see this idea as providing a brightly lit path for doing exactly this.

document somewhere that debuggers should try calling some getError or intoError method instead.

I see these statements as conflicting with my intent: to not require existing JS code or tooling to deal with objects that are not Error instances, but that have the semantics of errors. If you're describing an approach contained to wasm and its glue code, great, but it sounds like you describe requiring the ecosystem interacting with such wasm components to recognize these error-like objects.

IMO wasm components that create JS objects should create JS Error instances to represent things that have error/exception semantics, not a custom wasm gc object. If a reference to a wasm gc object is needed, the JS Error instance can be annotated with it (e.g. as a property defined on the JS Error instance)

[sjrd]

IMO wasm components that create JS objects should create JS Error instances to represent things that have error/exception semantics, not a custom wasm gc object. If a reference to a wasm gc object is needed, the JS Error instance can be annotated with it (e.g. as a property defined on the JS Error instance)

That's not very realistic, unfortunately. Languages have their own requirements on the semantics of their error objects: how they behave and how they interact with the rest of their value model. For example, Java exceptions are classes, which can implement interfaces. Those interfaces can also be implemented by regular, non error classes. If all the Java exception classes have to be JS objects, then those interfaces have to become a hybrid between Wasm and JS objects. So does java.lang.Object, which is the representation of most generics! Calls to any of their methods, or type tests, become extremely onerous, having to cross the Wasm-to-JS boundary. It's not a realistic implementation model.

Wrapping/unwrapping in a JS Error "view" of the exception for JS is problematic too. You cannot do it only when throwing/catching, because you could throw an exception, that JS would catch and store somewhere to be passed back normally to Wasm (for example, as a callback to Promise.then). So you would destroy the identity and semantics of your exception objects. And wrapping/unwrapping every time you cross the JS/Wasm boundary is practically impossible for performance reasons again.

We really want to define Wasm objects that can be treated as error objects, somehow.

[pfaffe]

This seems a little bit of an inversion to me. Engine debuggers are not the only things inspecting thrown values, and lots of code out there recognizes error instances, and I expect more-so now that we have Error.isError in the language.

+1 to this. Debuggers aren't the most interesting case here, they're powerful enough to dig out the stack in whatever way it's attached. The more difficult case will be logging (even simple things like console API or nodejs) and similar consumers of errors. There are tons of consumers like that and only a handful debuggers.

[tlively]

Ok, I would rephrase the question like this, then: It is clearly useful to have a common method for extracting Error objects from Wasm objects representing errors in any guest language. Should such a common method be documented as a tool convention, or should it be part of the standard so that other standard APIs can use it?

If we're not interested in complicating other APIs (the "tons of consumers") by having them call such a method, then making this a tool convention is sufficient. I think @mhofman has been saying that this is the case. But even if the "tons of consumers" are not updated to use such a common method, it would still be useful if debuggers used it. Would debuggers still use such a method if it were just a tool convention, @pfaffe?

[pfaffe]

If this is documented as a convention and has some noteworthy adoption I don't see any problem adding explicit support for it.

[sjrd]

If it's a convention, I guess it can't be a well-known symbol. It will probably have to be a string, or possibly a symbol constructed with Symbol.for. We'll need to find a string that isn't likely to collide with arbitrary other use cases, but that's probably doable.