Expression switch exception naming

[Cyrill]

I think that adding a single exception for this case will not be 
sufficient. Why not design the exceptions to be future proof, i.e. for 
extensions of the switch-expression/pattern-matching features, instead 
of single-casing or re-using existing Exceptions?

I'd suggest having the errors arising from the switch-expression form a 
subtree, inheriting from RuntimeException. As the base class, you could 
have MatchException, MatchFailureException, or similarly with Pattern-, 
but something that clearly relates to the feature in and of itself. The 
compiler could then, as right now, only Enum-matches are exhaustiveness 
checked, insert a more specific subtype to be thrown - i.e. your 
EnumConstantNotPresentException. (although "not present" kinda suggests 
that the value isn't present at runtime, when rather the check for it 
isn't there)

When sealed types are introduced and the compiler proves exhaustiveness 
over the sealed types, it can insert a SealedType...Exception? Naming 
something nicely is difficult, but that is beside the point right now I 
think.

What are your thoughts on this?

(If the ship of the exception related design has already sailed: Sorry)
- Cyrill


Am 28.03.2018 um 15:15 schrieb Gavin Bierman:
> Dear experts,
>
> We're busy putting the finishing touches to the spec for expression switches. Here's one issue that came up that we'd like your opinion on.
>
> Here is a part of the spec that deals with the dynamic semantics of expression switch
>
> -   If no pattern matches and there is no `default` pattern label, then
>     a **??** is thrown and the entire expression `switch` completes abruptly for that reason.
>
>
> So, the question is: What shall we call the **??** exception? There are two ways of looking at this:
>
> 1. The VM-centric view. Because the compiler checked that the expression switch was exhaustive, this can only have happened because someone has changed something after compilation. Right now that would be because we have added a new enum constant. In this case we could perhaps raise an "EnumConstantNotPresentException" exception. But we are planning to introduce sealed types in a future version, and we could run into a similar error, where clearly the exception name can't refer to an enum. We need something that covers all possible causes. Accordingly, we could go with something like "IncompatibleClassChangeException". Whilst accurate, one might fear that the average Java programmer will not find this an informative exception name.
>
> 2. The language-centric view. We should name this exception after the feature that has caused it to be raised. So "MatchFailureException", "PatternFailureException", "UnexpectedMatchException" might be possibilities. A worry here might be that other future features might want to raise this exception, and the name will be less applicable. Perhaps "UnexpectedValueException"?
>
>
> Your thoughts/suggestions much appreciated!
> Gavin