Preserve identity of exceptions from JS when passing through wasm #189
Comments
aheejin
added a commit
to aheejin/exception-handling
that referenced
this issue
Feb 4, 2022
This updates the explainer on - We add stack trace option to `Exception` class in the JS API - `Exception` can contain an optional `externref` to carry a stack trace - `Exception` is not a subclass of JS `Error` Addresses WebAssembly#183 and WebAssembly#189.
aheejin
added a commit
to aheejin/exception-handling
that referenced
this issue
Feb 4, 2022
This updates the explainer on - We add stack trace option to `Exception` class in the JS API - `Exception` can contain an optional `externref` to carry a stack trace - `Exception` is not a subclass of JS `Error` The WebIDL syntax is suggested by @eqrion in WebAssembly#183 (comment) and WebAssembly#183 (comment). Addresses WebAssembly#183 and WebAssembly#189.
This was referenced Feb 4, 2022
Ms2ger
pushed a commit
that referenced
this issue
Feb 10, 2022
This updates the explainer on - We add stack trace option to `Exception` class in the JS API - `Exception` can contain an optional `externref` to carry a stack trace - `Exception` is not a subclass of JS `Error` The WebIDL syntax is suggested by @eqrion in #183 (comment) and #183 (comment). Addresses #183 and #189.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Some discussion starting at #183 (comment) already.
Proposal: attach an optional
externrefto the core exception, and make sure it's propagated bycatch;rethrow, but not expose it to wasm code. Then hosts that don't need it, should be able to avoid storing it at all. The JS API spec can then extract that value when it gets an exception from wasm, or create a new one if there isn't one.The text was updated successfully, but these errors were encountered: