Heejin Ahn

@Ms2ger This issue is old so anyway fine to close, but I'm not sure the commit you closed this with is relevant to this issue in any way?

I don't think we can practically analyze the set of types of exceptions a specific function can throw unless every function signature embeds thrown exception signature within it. And changing...

> I think that this is useful for some languages where exceptions are declared or otherwise part of the type of a function, but would be a showstopper for other...

@PoignardAzur > * If a language uses a monadic or state-machine error model (eg [Rust's Result type](https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html)), exceptions specifiers would allow them to interface with functions that may throw exceptions,...

@lukewagner > Now let's imagine, in the future we're slowly moving toward where a single app can contain wasm code from multiple packages, each compiled by possibly-different toolchains, that we...

> > Can't this happen in MVP already? > > Technically, if a JS exception unwinds into wasm today, the [core wasm host function call rules](https://webassembly.github.io/spec/core/exec/instructions.html#host-functions) say that that is...

- Where would interface types take that `throws` info from then, if not from function types? As I said earlier, it is not practical to transitively scan the whole call...

What `getArg` returns is an `i32` value, which is a pointer to a C++ exception, which is returned by [`__cxa_allocate_exception`](https://github.com/emscripten-core/emscripten/blob/ac54c944baf1bc44c5444c44690b382d48555594/system/lib/libcxxabi/src/cxa_exception.cpp#L183) in libc++abi. The real C++ value thrown (what you can...

It looks this test gives examples of `getArg`'s usage: https://github.com/v8/v8/blob/17a99fec258bcc07ea9fc5e4fabcce259751db03/test/mjsunit/wasm/exceptions-api.js#L202-L225

Yes, it is a regular memory address.