Reconsider original extensible design

[RossTate]

I understand that it's frustrating to change to another design and then be advised to change back. But the discussion that led to that decision did not consider a number of important points, nor did it consider modifications to the original design that would have addressed its hypothetical weaknesses. Unfortunately the points that were not considered are the ones that most affect long-term possibilities for WebAssembly, and that leaves us with no real path for improvement/extension to accommodate more tooling or languages. As such, I encourage us to reconsider the original design strategy, albeit with some modifications, which does have a clear path for improvement/extension. The following is a summary of the issues that have been identified, a concrete suggestion based on these discussions, and an illustration of how that suggestion is extensible in ways the current proposal is not.

exnref has no exception-specific use

Firstly, I get the impression that many impose more purpose on exnref than it really has, and part of its appeal in the first place was people imagining it to be more than it is. So I want to start by tackling what exnref really is. To simplify this discussion, let's suppose anyref is back.

Suppose there were some way to declare "tags", like tag $mytag : [i32 externref], and we had operations new_tagged $tag : [t*] -> [anyref] (where tag $tag : [t*]), and extract_tagged $tag : [anyref] -> [t*] or br_on_tagged $tag $l : [anyref] -> [anyref] (where $l is a label of type [t*]). This is something that could be generally useful outside of exception handling. The point is that it gives us a way to create, test for, and branch on tagged references, i.e. open case types.

Then throw could take an arbitrary anyref, and catch could catch an arbitrary anyref, and rethrow has no purpose and could be removed. br_on_exn would simply be br_on_tagged.

This transformation loses no exception-handling functionality, which demonstrates that the current proposal has an extremely simple notion of exception handling, and that exnref has no real functionality specific to exception handling that a general-purpose open case type couldn't provide.

Stack traces

The counterargument I expect to hear is that exnref implicitly has a stack trace. But this stack trace is not visible within WebAssembly; it is not visible in the JS API; and it is not visible in C++. It's only visible as debug information. But we could recover that stack trace without exnref if we left the stack in tact when an exception is uncaught.

In some discussions, JavaScript's exception-handling design has been lamented for not associating a stack trace with the exception, which was one of the rationale's behind the design of exnref. But not having a stack trace with all throwable values is really not the problem with JS's exception handling. The problem is that JS's design makes it so hard to tell when an exception will not be caught that in the common case most of the stack has been unwound by the time the exception reaches the root of control. If not for that, a browser could print out the stack trace from typically its original throw after determining the exception was uncaught. The current proposal recreates that exact problem because it is essentially the same exception-handling design as JS. So the hidden stack traces of exnref are just a bandage over a much bigger problem with both JS and the current proposal.

Filtering exceptions

This issue of having unwound the stack by the time an exception is caught is much less prevalent in other languages because they have filtering mechanisms for determining whether a given catcher is really meant for a given exception. Unfortunately, it is very difficult to do this filtering in a general-purpose manner for WebAssembly without explicitly requiring two-phase exception handling (in which the search for the handler is done in one pass, potentially followed by unwinding of the stack in a second pass). Making throw and catch specify a tag (or event) does some filtering, but it is far too course-grained to be useful for most languages (including C++, due to subtyping). (Using tags is still helpful for determining that modules are throwing/catching completely unrelated exceptions, e.g. because they are compiled from different languages, and because tags make it so that we do not need anyref or memory management to do exception handling.)

A nice quality of the current design is that it's compatible with single-phase exception handling, which might be useful for simpler engines. But, unlike the original design before exnref, the current proposal produces code that is incompatible with two-phase exception handling due to bundling unwinding code with searching and catching code (JS, on the other hand, at least has finally clauses to separate these concerns).

So although it's reasonable, and in fact useful, to not have filtering in the MVP, it's concerning that it's already been established that an entirely new exception-handling design will be necessary to support more features like exception filtering and resumable exceptions.

Unwinding

It seems the main reason that the exnref design was chosen over the original was to avoid hypothetical duplication of destructor code (though no one noted that it doesn't actually do this in the common case where only one type of exception is caught). But this can be resolved by having a try/unwind instruction that executes the body of unwind when an exception is thrown from within the try block. The unwind block always has type [] -> [], meaning it does not get to examine the exception and by default returns control to the "unwinder" at the end. (Because of this, try/unwind actually doesn't need any type annotation, unlike try/catch.)

In addition to reducing code-duplication of destructors, try/unwind has the advantage of separating unwinding code from catching code, making it possible to add features for filtering and resuming exceptions without having to come up with an entire new exception-handling design. It also can be used to actually reduce code-duplication of destructors, because we could add (though probably not in the MVP) instructions like return_unwinding that would execute all unwind blocks the statement is nested within before returning from the function.

Rethrowing

There seems to be a misconception about rethrow. This instruction does not correspond to rethrowing in surface languages. In C++, try {...} catch (int x) {throw;} is semantically equivalent to try {...} catch (int x) {throw x;} (though this is not true for all exception types, though for reasons related to copy constructors rather than to rethrow). Python has a specific stack-trace semantics for rethrowing that is not served by rethrow. A rethrown exception in C# captures a new stack trace (actually, the stack trace is often collected during unwinding if it is needed at all).

The main purpose of rethrow is to propagate exceptions that the catcher does not understand after executing unwinding code. This value is obviated by making catchers only catch exceptions they understand (via tags) and by separating out unwinding code that does not care about the specific exception at all. In other words, rethrow only solves problems that the current proposal creates.

Putting it all together

Since I understand it helps to have concrete suggestions, especially given the late phase, here's what I would do to make exception-handling still simple and compatible with single-phase exception handling but also forwards-compatible with two-phase exception handling and the various exception-handling extensions that require that (as well as interactive debugging).

1. Rename events to tags (or something of the like) so that we have declarations like tag $tag : [t*]. They have utility beyond exception handling (though going into them here would be a digression) and so in the long run might be served by a more general name. And it's already been established that one of the reasons for naming them events and switching to exnref—namely supporting algebraic effects or resumable exceptions in the future—doesn't pan out.
2. Have an instruction throw $tag : [t*] -> unreachable, where tag $tag : [t*], that looks for the first matching handler up the stack, trapping if none exists.
3. Have an instruction try (do instr*) (catch $tag $l) : [ti*] -> [to*], where instr* : [ti*] -> [to*] and tag $tag : [t*] and label $l : [t*], that is a matching handler for throw $tag while control is within do, executing unwinders on the stack until control reaches $l.
4. Have an instruction try (do instr1*) (unwind instr2*) : [ti*] -> [to*], where instr1* : [ti*] -> [to*] and instr2* : [] -> [], that is an unwinder while control is within do. (If control exits the unwind clause other than reaching its end, that ends the unwinding process.)

An important point of flexibility is that handlers are not limited to catch, and unwinders are not limited to unwind. In particular, the host can have their own handlers and unwinders. For example, JS finally clauses can be considered unwinders. Also, to support single-phase exception handling a host just needs to have a (conceptual) universal handler at the root of the stack just to guarantee one always exists somewhere; these particular instructions cannot observe the difference between unwinding as you look for the matching handler and unwinding after you find the matching handler, so long as you know a matching handler exists.

The JS API would, as suggested above, treat finally clauses as unwinders. It would also treat JS throws and catches as using a special $jstag, which wasm modules could import with tag type [externref]. That's it; no need for wrapping and unwrapping. JS code doesn't (currently) have a way to catch wasm exceptions directly, but if a wasm throw has no handler, it'll trap, and JS can catch that trap. Of course, JS code always has the option of creating a wasm module to catch wasm exceptions, and we could make a JS API shorthand for that functionality if it's pressing.

Extensions

The main advantage of this change is that we can extend this variant much more easily. To illustrate that point, here are a few exceptions that come to mind.

1. Add an unwinding instruction modifier. That is, it's an instruction that modifies the behavior of the following (appropriate) instruction. In this case, the following instruction must be one that redirects control up the stack, specifically return and br-and-variants. Its effect is to execute all unwinders on the stack between that instruction and the targeted point of control. This in particular would be useful for implementing finally clauses in surface languages, as well as C++ destructors in more recent C++ semantics, instead of duplicating the code across the "successful" and "exceptional" paths.
2. Add try (do instr1*) (handle $tag instr2*) end : [ti*] -> [to*], where [instr1*] : [ti*] -> [to*] and tag $tag : [t*] and instr2* : [t*] -> []. This is a matching handler for throw $tag while control is within do, but unlike catch it doesn't necessarily cause the stack to unwind. Instead, the handle body is executed during the search phase, and if control reaches the end of the body then the search phase is continued. So you can do handle (if some-filter-expression then (unwinding (br $catcher))) to implement exception filtering. Or you can implement resumable exceptions by doing try (throw $exn_tag) (catch $resume_tag $resumer) around the exception throw, and then doing handle (... (throw $resume_tag)) in the handler to end the search and transfer control to $resumer with appropriate values. catch $tag $l itself is just shorthand for handle $tag (unwinding (br $l)).
3. Add catch_all and handle_all, which take no inputs and are universal handlers. At this point, it might be useful to let a try have multiple handlers, all for distinct tags, and then a universal handler that applies to all but those tags. Alternatively, catch_all/handle_all could take a list of tags they don't handle.

The list goes on, but the point is not to suggest that these be added now. The point is to illustrate that they can be added in a way that composes naturally with the suggested changes above (but which does not compose naturally with the current proposal).

Summary

As frustrating and painful as it is, I believe the above considerations strongly suggest that we should take exception handling back to its original, more extensible, design. Not doing so now will lead to even more frustration and pain down the line, since we'll want to create a two-phase-compatible exception-handling design at some point to support more languages and (debugging) tools, and then we'll be in the horrible spot of having two exception-handling designs in the same system, with one forcing single-phase exception handling and the other forcing two-phase exception handling, each jumping through hoops to interop with the other as best as they can manage.

[aheejin]

2. Have an instruction throw $tag : [t*] -> unreachable, where tag $tag : [t*], that looks for the first matching handler up the stack, trapping if none exists.

This effectively means "add two-phase stack unwinding", right? You made it sound really simple but this is not, and I think you very well know that. As I said before, this involves the VM calling some filtering function (in case of C++, the personality function) each time it unwinds the stack, which requires a separate stack to run these things, and the structure of the filtering functions or mechanisms differs greatly for each language, which makes an language-agnostic design very hard.

While I think two-phase unwinding is useful to have for tools like debuggers, it's not impossible to add one on top of the current proposal, albeit that won't be zero-cost. We can add the "traverse the stack and exit the program without unwinding the stack" functionality as library. This needs save some info to do this and this incurs costs even when exceptions are not thrown, but given that debuggers that examine stack traces will be used mostly with debug builds, adding this behavior only to debug build can make easy debugging possible while keeping the release build zero-cost. This library-based stack unwinding was also used in PNaCl. (It did this to both builds, and it didn't have zero-cost EH, but the mechanism is similar.) Adding two-phase EH in the spec level makes the interactions between VM and the code complicated and it can be tied too closely to some languages.

3. Have an instruction try (do instr*) (catch $tag $l) : [ti*] -> [to*], where instr* : [ti*] -> [to*] and tag $tag : [t*] and label $l : [t*], that is a matching handler for throw $tag while control is within do, executing unwinders on the stack until control reaches $l.

Not sure how this is different from the current try-catch. And I'm not sure if I understand your notations well. Please define terms before using.

4. Have an instruction try (do instr1*) (unwind instr2*) : [ti*] -> [to*], where instr1* : [ti*] -> [to*] and instr2* : [] -> [], that is an unwinder while control is within do. (If control exits the unwind clause other than reaching its end, that ends the unwinding process.)

We had many previous discussion history, but at the current stage exnref is not really for destructor code reuse. But it makes a lot of code transformations easier.

What you suggested here sounds like divide catch into two kinds, one for real catch and the other for destructors, right? While this is not impossible, I don't get the reasoning behind that.

[RossTate]

This effectively means "add two-phase stack unwinding", right?

No it does not. I tried to design this to be compatible with both single-phase and two-phase exception handling. As part of that goal, there is no custom filtering in this version.

Something's come up and I have to run at the moment (sorry for the bad timing), but you have good questions and I'll try to get back to them later today.

[RossTate]

2. Have an instruction throw $tag : [t*] -> unreachable, where tag $tag : [t*], that looks for the first matching handler up the stack, trapping if none exists.

This phrasing is suggestive of two-phase exception handling, but on it's own it does not require two-phase exception handling. That depends on the kinds of handlers that might be present. In particular, extensions aside, the only handler required to be possible is catch $tag $l. This kind of handler has the property that whether or not it causes stack unwinding can be determined in a pure manner. So there's no way to observe the difference between finding the handler and then unwinding (two-phase) versus unwinding and then finding the handler (single-phase).

But there is one important corner case which is when there is no matching handler at all, in which case you should trap before executing the unwinders. One way to avoid this is for an engine to have a universal handler at the root of the stack (the host is free to define it's own kinds of handlers in addition to the ones built into wasm), thereby guaranteeing such a handler will always exist and a throw will never trap. What's best for JS is not immediately obvious, but this design leaves room for multiple options due to host's being able to define their own kinds of handlers. Obviously we have to pick one before releasing, but that can be a separate focused discussion.

Not sure how this is different from the current try-catch.

The suggestion here has a $tag that tells you what kind of exceptions it's intended to catch (without running any custom code) and what the payload of that exception looks like. The current proposal requires running custom code to find out if the exception is meant to be caught (and that code might be in the same block of instructions as unwinding code).

And I'm not sure if I understand your notations well. Please define terms before using.

I tried my best to balance precision and concision. I'm happy to explain something in more detail if you let me know what particular thing(s) are unclear.

But it makes a lot of code transformations easier.

One other difference between catch here versus in the current proposal is that catch here does not have a body; it just specifies a label to redirect control to upon finding a match. I thought this might make it easier to still accommodate the transformations you had shown me earlier despite not having exnref.

What you suggested here sounds like divide catch into two kinds, one for real catch and the other for destructors, right? While this is not impossible, I don't get the reasoning behind that.

The idea is to separate the various components—search, filtering, unwinding, catching—so that they can be more easily combined in other ways. So if we do add a way to custom-filter exceptions or to resume exceptions, then we can do just the search components first, and later just unwinders in the appropriate phase (if at all). Right now the search code, catching code, and unwinding code is all in one block, so we can't search for a handler of a potentially-resumable exception without also unwinding the stack along the way and thereby making it impossible to resume the exception.

New item

I think we're both in agreement that it's generally better if we can manage to do more handler-filtering before necessarily unwinding the stack, but that for the MVP we also cannot use custom filtering code so that we're compatible with single-phase exception handling. One thing we could do with the design here is let throw take a (nonempty) list of tags (all of the same type)—a handler matches so long as it matches one of the tags in the list.

Then for C++ (and various other languages), one could have tags for coarse approximations of types. A C++ throw e; could translate to a wasm throw with the list of tags coarsely approximating the type of e and all its supertypes. A catch would specify the tag coarsely approximating the type it can handle. The more fine-grained the approximation is, the more filtering-before-unwinding this scheme will provide you. Probably not an MVP feature, but it's an example of an extension that would be compatible with both single- and two-phase exception handling.

[aheejin]

OK basically what you want is going back to the first proposal, with tagged catch and no first-class exnref, right? We spent so much time discussing this years ago, so I really don't want to repeat all that.

I'm not necessarily against making catch capable of taking optional tags. And I think having this option will leave the door open to the behavior you described: when no tags match, throw should trap without unwinding. But I still want to keep the current catch (which is catch_all) and first-class exnref. Code transformation is currently severely restricted without them. And because we have the optional tag capability of catch, we can switch to that version of catch later when we have time for it and if it turns out to be not detrimental to other factors (such as code size).

One other difference between catch here versus in the current proposal is that catch here does not have a body; it just specifies a label to redirect control to upon finding a match. I thought this might make it easier to still accommodate the transformations you had shown me earlier despite not having exnref.

Whether catch has a body or has a label is I think a choice of flavor, and not essential to the points you are suggesting. And actually if catch does not have a body, not having first-class exnref will become even bigger pain.

Also I'm not sure what you mean by "the transformations you had shown me earlier". I don't recall showing any transformation that will be made easier with labeled catches. I said (in reply to your direct email) there are many code transformations in LLVM backend (and also Binaryen, I should mention) that will be made very hard if we don't have first-class exnref. That's all I said.

One thing we could do with the design here is let throw take a (nonempty) list of tags (all of the same type)—a handler matches so long as it matches one of the tags in the list.

Then for C++ (and various other languages), one could have tags for coarse approximations of types.

This is not even feasible. There's no way to statically know a type of thrown C++ class type at the point of throwing. Also types in C++ class hierarchy and the actual type gets thrown in wasm (i32) are not even relevant.

---

What's makes it hard and frustrating with discuss on your argument is, you present many of your flavor-based choices as something essential to the core of your argument. (This long article is, nearly, "list of everything you suggested so far".) I think the core of your argument is that we should make the proposal more open to future possibilities of two-phase unwinding. And other than making catch capable of taking tags (which I suggest should be optional), I'm not sure why all other your suggestion of changes are essential to prevent "future frustration" you mentioned.

Also the other thing I consistently said and was ignored from you is, if some functionality may not be essential to make working code snippet from the spec's perspective but makes toolchain development much easier, it is a perfectly valid argument to keep it, such as first-class exnref. When we changed to the first to the current proposal, no one in the meeting thought it was impossible to generate working code without it. We decided based on the argument that it was convenient to have. You keep throwing some random feature of your proposal saying "if you have this new feature, your code transformation problem will go away even without exnref!" No. they don't.

[RossTate]

Also I'm not sure what you mean by "the transformations you had shown me earlier". I don't recall showing any transformation that will be made easier with labeled catches. I said (in reply to your direct email) there are many code transformations in LLVM backend (and also Binaryen, I should mention) that will be made very hard if we don't have first-class exnref. That's all I said.

You sent me this link. I read it to understand your concern. That took quite a while.

Here's how I thought my suggestion might address this concern. Notice that try/catch $tag $l is quite lightweight. In particular, because my catch is not a block, neither try nor catch needs a type annotation. This makes it much easier to insert my try/catch at very precise locations within the code. For example, I can place a try/catch $tag $l around each call instruction if I want. This has an effect similar to (though admittedly not identical to) the unwind specifier in LLVM. That is, it indicates where to redirect control to if the function call throws a matching exception. So, if you want, you can have block instructions at a coarse outer level, each providing a label to a particular exception catcher, and you can have fine-grained try/catch __cpp_exception $ls around each function call to indicate which handler that function call should go to.

But maybe it turns out that doesn't work. I can't know without you engaging in this discussion and sharing your expertise rather than lambasting me for trying to understand and suggest solutions to a significant extensibility issue that the current proposal seems to have.

[aheejin]

This makes it much easier to insert my try/catch at very precise locations within the code. For example, I can place a try/catch $tag $l around each call instruction if I want. This has an effect similar to (though admittedly not identical to) the unwind specifier in LLVM. That is, it indicates where to redirect control to if the function call throws a matching exception. So, if you want, you can have block instructions at a coarse outer level, each providing a label to a particular exception catcher, and you can have fine-grained try/catch __cpp_exception $ls around each function call to indicate which handler that function call should go to.

This will turn every single call instruction into 3 instructions, so I think the code size will suffer. We spent nontrivial amount of time brainstorming on things like this, such as #29. (This is not exactly the same as this, and this was when the proposal was the first version so not related to exnref, but it was suggested to tackle that mismatch of unwind destination issue. I'm not asking you to read the whole issue at all; just looking at a couple code snippets will be enough to get the feel.)

And while I understand you suggested this to solve the unwind destination mismatch problem in CFGStackify, I don't get how this is related to removing exnref or the "serious extensibility issue" you implied. I think all three are different things, so conflating them or presenting all of them as a essential steps to solve a single big problem doesn't help discussion.

This might (with significant code size increase) solve the mismatch problem, but in this scenario catch does not have blocks, then we need first-class exnref more than ever. exnref was omitted in the first proposal because catch was a block there was only one implicit exception we can refer to within the block. And while these two (unwind mismatch and first-class exnref) are separate issue, I can't see why either of this is related to the "extensibility concern" you mentioned.

But maybe it turns out that doesn't work. I can't know without you engaging in this discussion and sharing your expertise rather than lambasting me for trying to understand and suggest solutions to a significant extensibility issue that the current proposal seems to have.

I'm not sure what is that 'significant extensibility issue'. As I said, removing exnref is a separate thing that is unrelated to two-phase unwinding. If what you mean by the extensible issue here is that catch doesn't have tags, I said I'm open to add optional tags to them, but still want to keep catch_all and exnref. Does that not solve your "extensibility concern"?

[RossTate]

Rather than continue carrying two conversations at once, I'm going to focus on the bigger-picture one.

If what you mean by the extensible issue here is that catch doesn't have tags, I said I'm open to add optional tags to them, but still want to keep catch_all and exnref. Does that not solve your "extensibility concern"?

No. You still have the current design that bundles searching code, catching code, and unwinding code.

It would help me understand your perspective on the extensibility if you would illustrate how you expect to extend the proposal to accommodate these features. Here's a concrete case to consider:

Suppose I have a module compiled from the following C# code (where middle is some imported function):

bool flag;

int outer(bool b) {
    flag = b;
    try {
        return middle();
    } catch (Exception e) when (flag) {
        return 2;
    }
}

void inner() {
    try {
        thrower();
    } finally {
        flag = !flag;
    }
}

void thrower() { throw new Exception(); }

Next suppose middle comes from the following module compiled from C++ using this proposal (where inner is imported from the module above, although maybe via a funcref provided after instantiation to resolve the mutually recursive linking):

int middle() {
   Resource res; // some constructor; destructor crashes if ran twice
    try {
        inner();
        return 1;
    } catch (int x) {
        return x;
    }
}

I see two key challenges here. First, C#'s when clause is required to be evaluated before unwinding. So a call outer(true) is supposed to return 2, whereas a call outer(false) should leave the stack in tact so that a debugger can kick in. Second, we need to ensure the destruct or res only gets called once (and only if the inner exception is caught).

How are you expecting to extend this proposal to support this functionality, or more generally functionality that requires two-phase exception handling?

[aheejin]

First, please include only the suggestions that pertain to your extensibility example. Apparently not all your suggestions in the original post, which is a grab bag of everything you suggested so far in various issues, are related to this two phase thing. As I said above, conflating issues and presenting all of them as necessary steps don't help.

Also, it's hard to understand the purpose of that particular example.

So a call outer(true) is supposed to return 2, whereas a call outer(false) should leave the stack in tact so that a debugger can kick in.

How are you expecting to extend this proposal to support this functionality, or more generally functionality that requires two-phase exception handling?

The current proposal does not support the two-phase unwinding. This was not designed for it. But I'm not sure why going back to the first proposal will solve it either.

Second, we need to ensure the destruct or res only gets called once (and only if the inner exception is caught).

What makes you think the destructor for res will be called twice in the current proposal?

No. You still have the current design that bundles searching code, catching code, and unwinding code.

First, I don't understand why 'catching code' and 'unwinding code' should be separate. When we have two-phase unwinding, both of these should not run in the first searching phase. And both of those should run only when we find a matching EH pad.

Whether we should extend the current proposal to include two phase unwinding is another problem. As I said, I think it can be achieved in library level w/ the current proposal. But even if we extend the current proposal to include two-phase at some point, only searching code should be separated. And I think that searching code can be extracted into a function or something, whose address should be passed to the VM to be called. Probably catch should take one more argument, which represents the filter function. This will be more complicated in the VM level I think, because we need a separate stack to run it.

[RossTate]

I think you misunderstood the purpose of my last comment; sorry for not making that purpose clear. I started this thread expressing a concern about the extensibility of the current proposal. I also gave some constructive suggestions as to how to revise it in order to make it more extensible (and these revisions look more like the original design). You have been focusing on these suggestions rather than the extensibility concern. I am wondering if you do not share those concerns and, if so, if you could illustrate how you would extend the current proposal to accommodate features that use two-phase exception handling (like in the concrete example above). I am not suggesting adding those features now; I just want to know that they can be added at some point in the future. So, feeling free to ignore all of the suggestions I have made, could you illustrate how you would extend this proposal to accommodate the example program I gave and thereby help alleviate the concerns about forwards-compatibility with two-phase exception handling?

[aheejin]

I don't understand what exactly you mean by "extensibility". The current proposal doesn't support two-phase unwinding. Not sure if there is a grey area in which "we don't support it but we can be extended for it". If we make the next version of the proposal that supports more functionalities, its binary will not likely to be compatible with this version anyway. (Whether we should make the next version is a completely separate question. I'm being hypothetical.)

I also don't understand why all those things you said (first-class exnref removal, separating catch and unwind, and all other things you suggested here) help "extending" the current proposal. I think that's something you should prove, given that you come back to this point endlessly for months, before questioning why the current proposal cannot handle the two-phase unwinding, which we don't even claim to support. Also I don't get the point why I should "prove" that the current proposal can support two phase unwinding on your "specific example".

I also gave some constructive suggestions as to how to revise it in order to make it more extensible (and these revisions look more like the original design).

I don't even get how your numerous suggestions are related to whatever extensibility you claim. Again, that's something you should prove first. And I'm not really sure all those random suggestions which I can't even count anymore you threw in this repo have been constructive. I once asked you that if you are really concerned about a specific aspect of the proposal, please make each issue very specific to something you want to claim on that issue, rather than posting a big wall of text that is a grab bag of "all things you want to change for some reason". I don't think I was heard.

[RossTate]

I don't think I was heard.

You were heard. Unfortunately, the problem is fundamental to the current design and so can't be fixed by some small change like making tags optional. I have tried to illustrate that in a variety of ways. I'll try again using the above example.

void inner() {
    try {
        thrower();
    } finally {
        flag = !flag;
    }
}

First, when the exception is thrown by thrower(), it is important that the unwinder for the finally clause not be run because that will change the state in a way that affects the when clause in outer.

int middle() {
   Resource res; // some constructor; destructor crashes if ran twice
    try {
        inner();
        return 1;
    } catch (int x) {
        return x;
    }
}

Similarly, the destructors in the unwinder in middle should not be run. More generally this is because the exception could be resumed, but more specific to C# it's because the state affecting a when clause could also be modified by these destructors. (This is even part of .NET's C#/C++ intereporability semantics.)

It's not clear how to do this in the current proposal because the wasm catch needs to inspect the exception to determine if it's a C++ exception. This is where a tag on catch, rather than using exnref and br_on_exn, would help with forwards compatibility. So unfortunately this means that any design we make for exception handling with filtering will have to bypass all the catch clauses of the existing proposal. This means we'd effectively have two completely distinct exception-handling designs. It also means that catch in the current proposal would not serve as a catch-all.

But let's suppose we go forward with adding an entirely new exception-handling design. Even this still doesn't solve the problem, as I'll show next.

int outer(bool b) {
   flag = b;
   try {
       return middle();
   } catch (Exception e) when (flag) {
       return 2;
   }
}

Now when the search phase gets to outer, it checks the value of flag to determine whether or not the exception should be caught here.

If flag is false, the search goes on. If that search reaches the top, the stack is still in tact if a debugger wants to kick in or if simply the console wants to print out its stack trace.

If flag is true, then we need to unwind the stack up to this catch clause. That's where things get tricky.

With my design above, this is completely trivial. You just treat the relevant unwind blocks like little functions. Reaching the end of the block corresponds to that little function returning, granting control back to the unwinding operation which continues to the next unwind block until it reaches the target destination.

But with the current proposal, control is instead redirected dynamically using exnref. So the unwinding operation has to give each catch clause (which you skipped in the search phase) an exnref. But that exnref can outlive the lifetime of the catch clause and can be rethrown at any point, including even after the stack frame for outer has been popped off the stack. It sounds like the current plan for addressing this is to use first-class-stacks/continuations and store the continuation in the exnref.

So in order to extend the current proposal with just exception filtering, the plan seems to be/necessitate adding entirely new throwing and catching constructs that operate orthogonally to the existing ones (and yet supersede the existing ones in functionality) and then to use first-class-stacks/continuations in order to execute the unwinding code in programs written in the existing proposal. I would hardly call that an "extension". To me that's a complete redesign plus a heavy-weight backwards-compatibility patch for legacy code using the current proposal.

On the other hand, my design above is compatible with single-phase exception handling but can be extended with features like exception filtering by just adding a handle clause that can be easily implemented with two-phases exception handling (no first-class-stacks/continuations required). Critical to this extensibility is not using rethrow on exnref to redirect control, which is why the problem can't be fixed by something simple like optional tags.

Hope that clarifies the issue. I am trying very hard to explain a complex problem with just ASCII.

[tlively]

@aheejin and @RossTate, it looks like you both agree that the current proposal does not support two-phase unwinding and that it would require adding new primitives on top of those this proposal introduces in order to support two-phase unwinding in the future.

@aheejin thinks that this is fine because it is not a design goal of this proposal to consider two phase unwinding at all, so it makes perfect sense for that to be addressed in follow-on proposal. If that follow-on proposal cannot reuse most of the machinery from this proposal, then that's fine because it is a separate proposal anyway. As a result, @aheejin does not want to think about two-phase unwinding examples right now.

@RossTate would prefer that all kinds of exception handling, both one-phase and two-phase, use the same primitives, which would require this initial proposal to use different primitives. He thinks that having shared primitives in the long run is important enough to warrant design changes to this proposal. Illustrating the necessity of using different primitives to support two-phase unwinding requires looking at two-phase unwinding examples.

Let's settle this fundamental disagreement about design goals before diving into detailed explanations of any concrete problems or solutions.

[RossTate]

Thanks, @tlively, for the summary of concerns. I'll keep the discussion at a high level.

There's unfortunately a critical item missing from your summary (though I otherwise agree with your summary of my perspective).

Even if we were to develop an entirely new set of exception-handling instructions for two-phase exception handling, these programs will have to interoperate with programs written using the current design. Unfortunately, that will require adding not just two-phase exception handling, but also full-blown first-class stacks. That is, every time C# or Java—or even C++ programs wanting standard interactive debugging for uncaught exceptions—enters a surface-level try clause, they will have to allocate a new stack just saw that they can soundly run the unwinders buried in the catch clauses of the current proposal. The example above was an attempt to illustrate why this is the case. But it also seems that this same conclusion had already been previously independently arrived at according to here.

So it is not just a matter of taste. The current proposal significantly limits what features we can add to WebAssembly, or at least how those features can be implemented, with significant consequences in complexity and performance.

My preference is that we amend this proposal so that it is possible to add functionality associated with two-phase exception handling without also requiring first-class stacks/continuations. Based on the analysis above, that amendment seems to require that, at the least, unwinding code (such as destructors) be put in its own unwind block that does not use exnref to return control to unwinding, but instead returns control by reaching the end of the block. My suspicion is that, after doing this, catch blocks will very frequently follow a pattern that would be better served by using tags, but that revision is not strictly necessary to address my main concern.

[aheejin]

@RossTate

1. Tagged catches
   I think I understand where you are coming from a little better. But adding a filter function, which both does the tag check and runs an actual filter function to decide whether it should be caught, also can solve the problem. To have two-phase unwinding, catch has to take a filter function anyway.

2. Splitting catch and unwind
   You want this because unwind shouldn't run in the first phase? I'm not terribly opposed to this, but note that this also can be simulated catch with a filter function. (The filter function should be able to tell us one of these three scnarios: 1. the current exception should be caught 2. the current exception should not be caught 3. this EH pad is cleanup.)

3. Removal of first-class exnref
   I don't get this part at all. You mentioned something like first-class stack or continuation which this proposal is not even considering to embed in exnref.

But with the current proposal, control is instead redirected dynamically using exnref.

At least in the current proposal, exnref has nothing to do with control flow. It is a collection of value plus some auxiliary info, that's all.

So the unwinding operation has to give each catch clause (which you skipped in the search phase) an exnref. But that exnref can outlive the lifetime of the catch clause and can be rethrown at any point, including even after the stack frame for outer has been popped off the stack.

It is the toolchain's role not to generate incorrect code. We can generate incorrect code for any proposal if the toolchain tries to. We don't do that (unless there is a bug).

It sounds like the current plan for addressing this is to use first-class-stacks/continuations and store the continuation in the exnref.

No. This proposal does not associate exnref with first class stack or continuation or whatsoever.

So in order to extend the current proposal with just exception filtering, the plan seems to be/necessitate adding entirely new throwing and catching constructs that operate orthogonally to the existing ones (and yet supersede the existing ones in functionality) and then to use first-class-stacks/continuations in order to execute the unwinding code in programs written in the existing proposal.

Again, don't have a clue what you mean by relationship between exrnef and first class stack / continuations.

And also, I think I said this like million times now, we need exnref for code transformations such as what you've seen in CFGStackify. Could you please value what toolchain needs as legitimate causes?