Add overview on traps and JS API (#93)

This adds overview on traps not being caught by the `catch` instruction
and its relationship with the JS API.
Closes #1 and closes #89.

Author: aheejin

proposals/Exceptions.md

@@ -282,6 +282,30 @@ calls until a corresponding, enclosing try block is found. It may also associate
 a stack trace that can be used to report uncaught exceptions. However, the
 details of this is left to the embedder.
 
+### Traps and JS API
+
+The `catch` instruction catches exceptions generated by the `throw` instruction,
+but does not catch traps. The rationale for this is that in general traps are
+not locally recoverable and are not needed to be handled in local scopes like
+try-catch.
+
+The `catch` instruction catches foreign exceptions generated from calls to
+function imports as well, including JavaScript exceptions, with a few
+exceptions:
+1. In order to be consistent before and after a trap reaches a JavaScript frame,
+   the `catch` instruction does not catch exceptions generated from traps.
+1. The `catch` instruction does not catch JavaScript exceptions generated from
+   stack overflow and out of memory.
+
+Filtering these exceptions should be based on a predicate that is not observable
+by JavaScript. Traps currently generate instances of
+[`WebAssembly.RuntimeError`](https://webassembly.github.io/reference-types/js-api/#exceptiondef-runtimeerror),
+but this detail is not used to decide type. Implementations are supposed to
+specially mark non-catchable exceptions.
+([`instanceof`](https://tc39.es/ecma262/#sec-instanceofoperator) predicate can
+be intercepted in JS, and types of exceptions generated from stack overflow and
+out of memory are implementation-defined.)
+
 ## Changes to the text format
 
 This section describes change in the [instruction syntax