Clarification on handling of duplicate catch $exn clauses

[takikawa]

I'd like to ask for clarification on the intended semantics when there are duplicate catch $exn clauses for the new 2-phase compatible semantics. Sorry if this was already covered in previous discussions on the tagged catch proposal, I looked around a bit but couldn't find mention of it.

Given a snippet like the following:

  try
    throw $exn
  catch $exn
    ...
  catch $exn
    ... ;; unreachable?
  end

I've been guessing that the intended behavior is that this will validate and execute, but the second catch $exn will essentially be unreachable because the catch tags are checked in order. This was inferred from the text of the old tagged exception proposal, which says:

Once a catching try block is found for the throw, the operand stack is popped back to the size the operand stack had when the try block was entered. Then, tagged catch blocks are tried in the order they appear in the catching try block, until one matches.

Is that the correct interpretation of the behavior? (an alternative possibility I imagined was that validation could disallow duplicates, though that requires keeping more state around to track seen tags)

[RossTate]

Good thing to clarify. My guess is that you have the right interpretation. In fact, because exception tags can be imported, we cannot always statically determine if two tags are distinct. So either we disallow imported tags in multiple catches, or we add some distinctness-constraint mechanism for imports and exports, or we allow duplicate tags on multiple catches.

[tlively]

Using the first instance of a catch x and leaving any subsequent catch x instances to be dead code seems like the most straightforward semantics to me. Doing anything more complicated would not be worth it.

[rossberg]

Agreeing with @tlively. Tracking this in the type system would not be worth the complexity. Worse, it may actually be counterproductive for some source languages that would want to make direct use of Wasm exceptions, because their type systems do not usually track exception disjointness either -- a compiler could not necessarily know what to assume/require for separately compiled modules. (And obviously, disallowing imported tags would break modularity entirely.)

[RossTate]

(I should clarify that my preference is also to allow overlap and go with the first match.)

[aheejin]

I also agree that matching first instance and discard the duplicates is the simplest. I'll add that case in the explainer too. I guess then the issue seems resolved, so I'll close the issue. Please feel free to reopen if there are remaining concerns.

@RossTate Imported exceptions don't matter here. The only thing catch sees is a number, which is an index to the exception index space. Those space can be occupied by both imported and non-imported exceptions.