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.bier...@oracle.com> > À: "amber-spec-experts" <amber-spec-experts@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
