What counts as an exception?

[KarlSchimpf]

Restoring lost issue:

@wibblymat

Should things like unreachable, out-of-bounds memory access, call_indirect with an invalid table index, etc., become catchable exceptions?

[dschuff]

I think there is a meaningful difference between explicitly-raised exceptions (which I guess includes JS exceptions but ignoring that for now) and machine-type error traps (OOB, signature mismatch etc) and it's not clear that they should be catchable in the same way that user exceptions are. So obviously we can debate that in this issue (and we can design such a feature) but I think the first proposal should exclude them because the use cases are very different.

[jfbastien]

Right, we've talked about having support for signals as well as exceptions. It would be interesting to define what we see in each bucket, and what other platforms have done. Specifically, I think the Windows SEH approach, its ups and downs, can inform our decision.

[AndrewScheidecker]

One advantage the Windows SEH approach has over handling runtime traps with signals is that it avoids global state that determines how a trap will be handled. There isn't a good way with POSIX signals to handle a trap from just one thread.

A Windows SEH filter is effectively a stack-scoped signal handler: when an exception occurs, the SEH filter functions are called "on top" of the stack, so the information is still available to resume execution, or get a stack trace, or unwind to the handler. A C++ catch maps to a SEH filter that checks the exception information and returns a value that indicates the associated handler should be executed.

Thread-local signal handlers would provide the same functionality (could you throw from them?), but require some additional mechanism to compose (a stack of handlers, perhaps?).

My most preferred design would be very close to Windows SEH. My least preferred design would be something that unifies traps and exceptions, but doesn't allow resuming or inspecting the stack at the trapping code.

[KarlSchimpf]

This proposal intentionally did not focus on what exceptions should be produced by WebAsembly. Rather, any such exception would need to be imported to be caught, since it is not one the module defines.

Hence, the framework needed to handle such exceptions, should they be added, is already there. We would not need to add any new concepts.

[AndrewScheidecker]

Hence, the framework needed to handle such exceptions, should they be added, is already there. We would not need to add any new concepts.

If runtime-generated traps can be caught as exceptions, then there should be a mechanism to retry the trapping code. There should also be a way to handle a runtime trap by capturing a stack trace and other state information at the point of the trap for automatic bug reporting.

I think it's fine to start with exceptions as they are and add the ability to catch runtime traps later, but there's additional functionality required if the above cases are to be supported. Would that require changing any of base exception functionality?

I can imagine adding a retry_throw operator that can be used similarly to the rethrow operator. That seems like it is orthogonal to this proposal.

A way to capture a stack trace is not specified by WebAssembly; without considering whether it should be, what would be needed from this proposal for an implementation to expose the trapping call stack to a runtime trap handler?

[KarlSchimpf]

Good point. I hadn't thought of those issues. I agree that sometime in the future, we should consider runtime traps.

[KarlSchimpf]

Marked as (future) enhancement to add handling of runtime traps.

[jfbastien]

I don't think we want to outright declare this as a future feature. It's worth exploring having it in the first version as well, and if that's not viable then move to future.

[rossberg]

@jfbastien, are you referring to reifying traps as exceptions, or supporting resumption? Both are separate features, and the latter is far more difficult and debatable than the former.

[jfbastien]

@jfbastien, are you referring to reifying traps as exceptions, or supporting resumption?

Both, separately.

Both are separate features, and the latter is far more difficult and debatable than the former.

Agreed.

[lukewagner]

At least in the future I've been imagining, the distinction between traps and exceptions is:

• traps: execute at the instruction, as if they were called by the instruction, can inspect local and stack state, and finally choose how to proceed, either by: (1) resume (with one of several suboptions here depending on the faulting instruction category, e.g., "resume with this value" for value-producing insns), (2) throw (with a given exception tag)
• exceptions are all about unwinding to an enclosing try block, taking for granted that this instruction has already chosen to throw.

With this distinction, exception handling is single-pass unwind-as-you-go, unlike, e.g., itanium ABI's two-pass design. Also, it is an orthogonal question of how to define which trap handler to call (module-scoped, lexically-scoped, dynamically-scoped like SEH, etc).

Also, with this split, trap handlers are definitely the more advanced feature with the more narrow (but important, in the limit, if we want to allow all the fancy VM tricks) use case, so I think we should keep them separate from the exception handling MVP knowing they can be added later in a complementary way.

[jfbastien]

knowing they can be added later in a complementary way

That's the bit I'm not convinced about.

[lukewagner]

Is there are particular scenario you're thinking about?

[jfbastien]

Is there are particular scenario you're thinking about?

Maybe I haven't thought about it enough. I'm not convinced this ins't a plausible scenario:

1. We standardize exceptions.
2. We want traps.
3. Traps are kinda different from exceptions, but not that much, and turn out to be incompatible in a weird way.
4. We end up with two mechanisms that are almost, but not quite, the same.
5. We're sad.

I'm just not convinced this isn't the case. As well as the above scenario, it could unfold as:

• We standardize both at the same time (either as one feature or as two), it works great.
• We standardize one then the other, but they magically coexist well.