Restore rethrow's immediate argument?

[aheejin]

We left out rethrows immediate argument in the last CG meeting's poll because we weren't sure about the use cases, but @rossberg suggested one in #125 (comment).

I think having this functionality is in general good as long as there exist languages that

• Use rethrow instruction for their rethrowing functionality, i.e., want to relay some auxiliary info when rethrowing
• Can specify an exception to rethrow from the stack of exceptions, as in the example in Proposed spec changes + rethrow question #125 (comment).

What do you think?

[fgmccabe]

This seems odd to me. Different languages have different semantics for throwing exceptions in general, including rethrow.
It seems pretty unlikely that a single low level mechanism will be cover all the conflicting requirements.
A better approach IMO would be to look at how the throw instruction would work in a rethrow situation.
TLDR; this feels like the wrong question (should rethrow take an immediate).

[aheejin]

@fgmccabe

A better approach IMO would be to look at how the throw instruction would work in a rethrow situation.

I'm not exactly sure what this means. Do you mean, can we use throw instead for rethrowing, which in turn means "should we even keep rethrow"?

I think having two kinds of throwing instruction, currently throw and rethrow, offers more options to language implementors. Some languages, such as C++, do not need that functionality, but other languages might. And both the current proposal and the newly-decided proposal have it. I didn't mean to re-discuss whether we should keep rethrow or not here. (If someone wants to discuss it, it is a separate discussion.)

Restoring the immediate means whether we should allow rethrow to choose an exception to rethrow other than the topmost (or the recent-most) one, and that was the focus of this issue.

[RossTate]

It's hard to discuss tradeoffs between design alternatives for a feature without known use cases for the feature. I think what @fgmccabe is noting is that, when you consider the potential use cases, you don't find much consistency. For example, Java, Python, and C# each have different semantics for rethrowing exceptions. But maybe those are not meant to line up with the rethrow instruction. So having concrete examples of how rethrow would be used would help facilitate this discussion.

[takikawa]

I read the justification for including this that @rossberg posted, and I agree that making nesting of handlers easier/possible is a natural choice from the language semantics point of view.

However I'm a bit concerned about the complication for implementing this, as I think the immediate argument for rethrow effectively introduces an implicit exception stack that's separate from the normal value stack (the previous design with exnref was more consistent in this regard, with everything being on the value stack). This second stack may need to be explicitly tracked by an implementation, to ensure outer exception references remain live.

[tlively]

Is it correct that rethrow-with-immediate can always be emulated by adding a branch out to the correct catch scope and then doing a rethrow-without-immediate? If so, I'm not convinced by the composability argument since that's a fairly simple transformation. I would be convinced if we had a usecase where rethrow-with-immediate would be used often enough that there would be a code size win from not having to do that transformation, but given our lack of rethrow use cases, I don't think that's a compelling hypothetical, either.

[aheejin]

@takikawa

However I'm a bit concerned about the complication for implementing this, as I think the immediate argument for rethrow effectively introduces an implicit exception stack that's separate from the normal value stack (the previous design with exnref was more consistent in this regard, with everything being on the value stack). This second stack may need to be explicitly tracked by an implementation, to ensure outer exception references remain live.

Don't you need to keep this exception stack anyway even without the immediate argument? As @tlively said, we can still go from the inner catch scope to outer catch scope (by a branch or fallthrough) and rethrow the outer exception from there.

[aheejin]

@tlively

Is it correct that rethrow-with-immediate can always be emulated by adding a branch out to the correct catch scope and then doing a rethrow-without-immediate?

I think so.

but given our lack of rethrow use cases, I don't think that's a compelling hypothetical, either.

For C++ we lack use cases, but for languages that use rethrow functionality like that in #125 (comment), I'm not sure..?

[RossTate]

That comment does not refer to any actual language. We currently have zero use cases. Python and C# both modify their exceptions when they rethrow them, and so they would have to implement their rethrow with throw of a new exception payload. Java could just as easily throw the rethrown exception. So we have multiple languages that would not use a rethrow instruction to implement exception rethrowing, and we have another language that could just as well implement exception rethrowing with throw.

Without knowing what rethrow is useful for, we cannot evaluate its design alternatives. The clever translation @tlively gave may or may not work depending on what rethrow is supposed to be doing. Until we have concrete examples of how it's supposed to be used and what purpose it's supposed to fulfill, we can all picture different variations of what rethrow does and is for and unintentionally speak past each other. We cannot effectively design features without use cases for those features.

[takikawa]

Don't you need to keep this exception stack anyway even without the immediate argument?

@aheejin Thanks, I think you're right about this, nevermind my comment about rethrow then.

[rossberg]

@aheejin, I have a really dumb question: how did you implement a correct semantics of finally or destructors under the previous proposal without using rethrow? As far as I can tell, rethrow is the only way to (re)throw exceptions whose constructor you don't know. It seems that if you don't use rethrow then any such feature will misbehave on foreign exceptions, e.g., JS ones.

[aheejin]

@rossberg
(I wrote and deleted a comment just not and please ignore that)

Sorry, I think I said something confusing. Our C++ implementation currently uses rethrow for

1. When an (both C++ and foreign) exception doesn't match the current catch. The current catch catches everything. With the new proposal decided, we use catch (C++ tag), but that doesn't mean we catch all C++ exceptions (i.e., in some catch we only catch int or something), so we have to still use rethrow if an exception doesn't match. This use case is actually not rethrowing but resuming, and it will be replaced by filter functions/blocks after two-phase unwinding is introduced later. In the current single-phase, rethrowing and resuming aren't different.

2. After running destructors. This is also a resuming behavior and will be replaced by try-unwind-end. (In the single phase, the exception will be effectively rethrown at the end, even though there's no explicit rethrow). C++ doesn't have finally, but for the languages that have it, clang compiles it away, so it will be handled in a similar way as destructor blocks.

What I tried to say was we don't use rethrow for C++'s throw;, which is C++'s rethrowing keyword, but apparently I said things in a very confusing way. The reason is C++'s throw; apparently doesn't preserve stack traces. Our current C++ implementation prototype's catch (...) doesn't catch foreign exceptions, mainly for implementation simplicity. We may want to change this later.

[rossberg]

@aheejin, that makes sense, thanks for the clarification.

So this seems to imply that we clearly need rethrow, unless we want to introduce all of two-phase unwinding now.

[RossTate]

As far as I can tell, rethrow is the only way to (re)throw exceptions whose constructor you don't know.

The current catch catches everything. With the new proposal decided, we use catch (C++ tag), but that doesn't mean we catch all C++ exceptions (i.e., in some catch we only catch int or something), so we have to still use rethrow if an exception doesn't match.

Notice that this is "rethrowing" an exception with a known tag and available payload. rethrow is not necessary for this. You can just use throw, and the two programs would be semantically equivalent.

[aheejin]

@RossTate

Notice that this is "rethrowing" an exception with a known tag and available payload. rethrow is not necessary for this. You can just use throw, and the two programs would be semantically equivalent.

Without rethrow,

1. We have to remember the order of extracted values and reconstruct them, and the bookeeping necessary for that may not be easy.
2. This also increases code size.
3. Also note that this is different from C++ throw;. C++ throw; doesn't preserve stack traces but this should. This is effectively uncaught exception and should be skipped by a filter function later when we have two-phase, so in the single phase, in case stack traces are embedded in the exception, this shouldn't be lost.

I think we have a very clear use case for rethrow in the current toolchain for all these reasons. And also, I think we agreed on the proposed spec like yesterday...? Not sure if we want to spend more time to discuss taking something out of that agreed spec only after a day. I opened this issue to discuss whether we need the immediate for rethrow.

[RossTate]

1. You put the payload (which I believe for C++ is currently just an i32) in a local variable. There are likely other reasons to do this anyways (e.g. to access the payload multiple times).
2. Barely.
3. Stack traces are not part of the semantics of WebAssembly exceptions. They are a debugging tool, and there are other, more robust ways for engines to track stack traces to this end.

I opened this issue to discuss whether we need the immediate for rethrow.

For me, the answer depends on what rethrow means and how rethrow will be used. That said, it does sound like there's reason to believe that every hypothetical use does not need an immediate, so I'm personally fine with you closing the issue with that answer.