Heejin Ahn

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

@sbc100 > I wonder how hard it would be to add wabt support for the latest exception handling changes? @aheejin ? Not sure, because I'm not very familiar with the...

https://github.com/WebAssembly/exception-handling/pull/218#issuecomment-1249470094 is about preserving exception identities and not about being able to extract JS exceptions from Wasm side. https://github.com/WebAssembly/exception-handling/pull/218#issuecomment-1249470094 basically says, if JS throws an exception and it passes through...

> The current strategy I have to take is wrapping the body of any JS FFI that may throw (due to transitively calling something that may throw) in a `try`/`catch`...

This is unrelated to the new `--translate-to-new-eh`. Parsing of `delegate` targeting a block has never been supported in Binaryen. Yes it is allowed in the spec, but because our primary...

Is this generally helpful even when the replacement is not a child of the original? In case it is not, is inaccurate info better than no info?

As long as they are JS exceptions, Wasm EH instructions will treat that as such, meaning, `catch_all` will catch it and tagged `catch` can also catch it if a module...

For `catch_all` catching JS exceptions, it has been supported for long time now. For `catch` catching JS exceptions with the imported JS tag, it was [recently added](https://chromium-review.googlesource.com/c/v8/v8/+/4508923) in V8 and...

I'm planning to work on it. In the meantime, we provide a translator in Binaryen that translates old binaries to the new ones. You can use it via `wasm-opt --experimental-new-eh`....

+1 on adding tests for `try` + `br`. But the spec tests may not necessarily need to fire the wasm2c bug? If our purpose is testing a `br` within a...