-
Notifications
You must be signed in to change notification settings - Fork 36
Simplify exception dispatch to branches #58
Comments
And complementary to the semantics I gave here, these are the rules for the alternative construct, replacing Syntax
Typing
Reduction
|
Interesting. I also was a bit concerned about making everything a block, so it's nice that this avoids that. The structure it requires seems a bit more awkward, but I suppose it's only as awkward as the |
My first impression is that I like this proposal. It's nice that we can just add an instruction rather than a new block type. I'm curious how this would affect the tools. I got the sense that |
Actually, I'm currently doing the prototype implementation based on the first proposal with one modification, which is Before changing to this, I tried to implement |
This proposes to use the idea suggested by WebAssembly#58 instead of `if_except`.
This proposes to use the idea suggested by WebAssembly#58 on using `br_on_exn` instead of `if_except`.
This proposes to use the idea suggested by #58 on using `br_on_exn` instead of `if_except`.
Closed by #71. |
This proposes to use the idea suggested by WebAssembly#58 on using `br_on_exn` instead of `if_except`.
The current
if_except
for handling exceptions is a structured instruction and as such quite complex. For example, embodying blocks, it has to deal with block signatures, labels, etc.In the context of working on the GC proposal, where a similar construct is needed for downcasts, I realised that we probably don't want to introduce a zoo of block constructs. And it turns out that with the multi-value proposal we can simplify all these by replacing them with simple branches.
For the exception proposal, this would mean that instead of the structured
if_except
construct, we simply have a new branch of the formwhich checks whether the exception package on the top of the stack matches the exception denoted by
<exnidx>
, and if so, branches to<labelidx>
. The trick, however, is that the block signature of the branch target has to be compatible with the exception's tag type -- because it receives the exception arguments as branch operands. If the exception does not match, it remains on the stack.For example:
This can now be used to construct handler switches in the same way
br_table
is used to construct regular switch:I think this is a simpler primitive and makes better reuse of existing instructions. (The
try
construct remains unchanged.) WDYT?The text was updated successfully, but these errors were encountered: