Expression switch exception naming

[Remi Forax]

NoCaseMatchError (or any other name) which is a subtype of IncompatibleClassChangeError.

Rational:
the compiler already checks that the pattern is exhaustive or emit a compile error, so it means that there is an issue at runtime it's due to the separate compilation problem.
So it will be a rare condition, thus it should be an error and not a runtime exception.

We already have different subtypes of IncompatibleClassChangeError depending on the exact problem, IllegalAccessError, AbstractMethodError etc, having a case missing should just be another subtype. 

Rémi

----- Mail original -----
> De: "Gavin Bierman" <gavin.bierman at oracle.com>
> À: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mercredi 28 Mars 2018 15:15:33
> Objet: Expression switch exception naming

> 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