Expression switch exception naming

[Kevin Bourrillion]

I'd almost hit send on the very same point... is it correct that this
situation is described exactly by "Thrown when an incompatible class change
has occurred to some class definition. The definition of some class, on
which the currently executing method depends, has since changed."?

If that shoe fits, we should wear it, and in naming our new subtype we
should attempt consistency with: AbstractMethodError, IllegalAccessError,
InstantiationError, NoSuchFieldError, NoSuchMethodError.



On Wed, Mar 28, 2018 at 8:19 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> 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
>



-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180328/572f636d/attachment.html>