Remove "terminate" / describe uncaught exceptions

[lukewagner]

In the Overview, Throws and Debugging sections, an uncaught exception is described to terminate the application/execution/thread. Thus far, there is not a "terminate" concept in webassembly and, e.g., after a trap, the semantics explicitly allow the host environment to call exports in the future. E.g., wasm has no problem with this JS:

var code = text2binary(`(module (func (export "yay")) (func (export "boo") unreachable))`);
var i = new WebAssembly.Instance(new WebAssembly.Module(code));
i.exports.yay();
try { i.exports.boo() } catch(e) {}
i.exports.yay();

I think we should have the same semantics for uncaught exceptions. Moreover, in a host environment (like JS/Web) which allows interleaved activations JS -> wasm -> JS -> wasm, an exception thrown by the inner wasm activation can be caught by the outer wasm activation.

It'd be good to spell this all out explicitly and remove any use of "terminate".

[KarlSchimpf]

I agree that the meaning of what happens if uncaught should not be (necessarily) termination. Rather it should be defined by the host for which the WebAssembly module is embedded.

Therefore, for JS, it should do what JS typically does.

I'm working on adding an additional section to the proposal for the case where WebAssembly modules are embedded in JS. In such cases, we can covert the "opaque" concept of exceptions (in the exception section) to a JS "WasmException", derived from JS Error or RuntimeError. These exceptions will add a "values" field corresponding to the thrown values.