Consolidate throw and rethrow

[RossTate]

I think the original reasons for keeping these as distinct concepts have sort of dissolved(?). (I have no idea what the right word to use is.)

We should have just new_exn or alloc_exn or something of the like, and throw but taking an exnref.

If it helps prove the point here's how you can implement new_exn $exception now:

try { throw $event } catch {}

[rossberg]

No, they haven't. Rethrow operates on an exnpackage, which generally contains more information than just the exception value. In practice, e.g. a stack trace that is copied over on rethrow, but newly generated on throw.

More interestingly, if you were to add resumption, then the exnpackage would carry a continuation, and that is also only captured by throw, not by rethrow. So they are fundamentally different operations.

[RossTate]

In practice, e.g. a stack trace that is copied over on rethrow, but newly generated on throw.

WebAssembly does not have a stack-trace semantics, nor does C++, nor does JavaScript. Java, C#, and Python do have stack-trace semantics, and all of them are different. There is no practice here; it's all ad hoc. Regardless, there's nothing preventing my revised throw from preserving the stack trace.

More interestingly, if you were to add resumption, then the exnpackage would carry a continuation, and that is also only captured by throw, not by rethrow.

As you also noted twice, you can't use this design for resumable exceptions. The C++ destructors on the stack can already have executed by the time the handler is reached.

But now I realize it doesn't matter anyways. My suggestion is equivalent to the current proposal, as in the two can encode the other. But it has a clearer separation of functionality: one instruction for creating the exception, and one exception for raising the exception.

[aheejin]

I think this is mostly a choice of flavor. We considered splitting those instructions too, and ended up with the current throw for simplicity (and one less instruction). Not sure if it's worth revisiting this unless there's a serious issue.

[rossberg]

There is no practice here; it's all ad hoc.

Agreed it's all ad-hoc, but it still is rather relevant practice. This has been an actual pain point in JS engines, for example, where the language fails to make this distinction, and there is no viable implementation strategy that does not loose stack traces in some cases.

Regardless, there's nothing preventing my revised throw from preserving the stack trace.

I think you could only do this by either mutating the exception value, i.e., expose the same hacky behaviour as JS, or worse, by mutating some global state.

you can't use this design for resumable exceptions

Probably true, but consider these two as examples of why it's better to assume that there is a conceptual difference between the two operations. And hence that it is more conservative to separate them.

[RossTate]

@aheejin, your parenthetical makes me think there's a misunderstanding. I'm suggesting replacing two instructions, throw and rethrow, with two instructions, new_exn and throw (where the latter is just rethrow renamed). So neither version has fewer instructions.

I think you could only do this by either mutating the exception value, i.e., expose the same hacky behaviour as JS, or worse, by mutating some global state.

@rossberg, you can collect the trace when you execute new_exn and store it once-and-forall in the new exnref. throw doesn't touch the stack trace. This is the same semantics given by the translation of these instructions into the current proposal.

I do not follow your last argument.

[aheejin]

@aheejin, your parenthetical makes me think there's a misunderstanding. I'm suggesting replacing two instructions, throw and rethrow, with two instructions, new_exn and throw (where the latter is just rethrow renamed). So neither version has fewer instructions.

What I meant by fewer instructions is in terms of the number of instructions used in real code. When you throw an exception, now we can do it with a single throw, whereas in your version we need two instructions to achieve the same thing.

This difference may not be very significant in terms of final code size given that throwing exceptions is rare, but it's still simpler. That's the reason why I said this is mostly a choice of flavor.

[aheejin]

Sorry I was going to click "Comment" button I accidentally clicked "Close and comment" button. Reopened the issue.

[RossTate]

Ah, thanks for the clarification!

[rossberg]

@RossTate:

I think you could only do this by either mutating the exception value, i.e., expose the same hacky behaviour as JS, or worse, by mutating some global state.

@rossberg, you can collect the trace when you execute new_exn and store it once-and-forall in the new exnref. throw doesn't touch the stack trace.

But the stack trace ought to be captures at the throw point, not the point where you create the value, which might be somewhere else entirely. Likewise, you may want to amend the trace upon rethrow, because again that may happen somewhere else entirely than where the catch was.

I do not follow your last argument.

We can think of two examples of meta data that one might include into exception packages (traces, continuations). For both we already know that the suggested approach cannot generally produce the correct behaviour. That's a strong indication to be careful and not conflate two operations that behave differently.

[RossTate]

But the stack trace ought to be captures at the throw point

I don't understand how you can make statements about what stack-trace semantics ought to be. Different languages have different semantics (including collect the stack trace at the point of allocation). WebAssembly should not be prescribing which of these is correct; it should be providing infrastructure to support each of these semantics and let the language implementer choose which to use. (And I doubt either of us have enough knowledge of the debugging literature to know which semantics is best anyways, supposing any best practice has even been established.)

We can think of two examples of meta data that one might include into exception packages (traces, continuations).

As mentioned above, neither of these pan out. If a host chooses to associate a stack trace for some internal purpose, however it does so is guaranteed to be arbitrary. If you were to associate a continuation, you wouldn't want to use it because a number of the destructors on the stack have generally been executed already. And regardless, even if you did do these two things, the translation I gave above is still semantics preserving (assuming program equivalences that I think we both agreed we expected to hold in other conversations).

That's a strong indication to be careful and not conflate two operations that behave differently.

@aheejin gave an observable difference between the suggestion above and the status quo, and an argument based on that difference as to why to prefer the status quo. @rossberg, as I believe you are the originator of this design, can you give a similar observable difference (or a useful concrete extension in which this difference matters) to justify this claim?

[rossberg]

@RossTate, one main motivation for the current design was that we wanted to keep the door open for resumption. As mentioned, throw and rethrow are very different primitives in the presence of resumption. Moreover, the return type of a throw depends on the exception constructor. It is more natural to have throw applied to a constructor, symmetrically determining both in and out type (this is standard in effect systems, too). You could still separate exception construction and throw, but that requires more tedious typing machinery to track the resumption type.

In short, if you ever want resumption, then separating rethrow is a must, and not separating exn creation is more natural.

I think we also wanted to avoid introducing an extra type of exception values, which again raises issues about life time management etc.

If you were to associate a continuation, you wouldn't want to use it because a number of the destructors on the stack have generally been executed already.

No, as I pointed out before, that's not how destructors (or any finalizers) can work in the presence of resumable exceptions. They must not run when a resumable exception is thrown, that would be a broken semantics. Instead, a separate abort/finalize primitive is needed (which could be provided by means of injecting an unresumable exception, as in our design).

[RossTate]

Okay, it seems it will help clarify things if you explain how you plan to address the following:

event $res : [i32] -> [i32]
event $err : [i32];

try {
    do some constructor;
    try {
         if (flip_some_coin()) {
             throw $res (i32.const 1);
         } else {
             throw $err (i32.const 5);
         }
    } catch {
         do some destructor;
         rethrow caught exnref;
    }
    do some destructor;
} catch {
    if (flip_some_coin()) {
        resume caught exnref with (i32.const 5);
    }
}

Suppose the try/catch destructor code in the middle is really in some other module than the innermost and outermost code. How is it supposed to know that 1) the exnref is resumable 2) that the exnref will be resumed?