Expression switch exception naming

[forax at univ-mlv.fr]

Do we have another case where we actually throw a runtime exception due to a separate compilation issue ?

Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Kevin Bourrillion" <kevinb at google.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 30 Mars 2018 20:44:23
> Objet: Re: Expression switch exception naming

> I'm not talking about recovering.  This is purely taxonomy; this sort of
> mismatch does not (IMO) rise to the level of Error.
> 
> On 3/30/2018 2:42 PM, Remi Forax wrote:
>> You still have not explain why you want to recover from one of these exception
>> knowning that it's simpler to add a default if you want to take care of an
>> unknown enum constant.
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "Kevin Bourrillion" <kevinb at google.com>
>>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>>> Envoyé: Vendredi 30 Mars 2018 20:39:30
>>> Objet: Re: Expression switch exception naming
>>>> All right, I've been focusing too much on the hierarchy, but the
>>>> leaf-level name is more important than that (and the message text
>>>> further still, and since I assume we'll do a fine job of that, I can
>>>> probably relax a little). To answer your question, sure, the "ICC" is
>>>> a pretty decent signal. Have we discussed Cyrill's point on -observers
>>>> that we should create more specific exception types, such as
>>>> UnrecognizedEnumConstantE{rror,xception}?
>>> Yes.  What I'd been proposing was something like:
>>>
>>> class IncompatibleClassChangeException <: Exception
>>> or
>>> classUnexpectedClassChangeException <: Exception
>>>
>>> and then
>>>
>>> UnexpectedEnumConstantException <: {I,U}CCE
>>> UnexpectedSealedTypeException <: {I,U}CCE
>>>
>>>
>>>> Okay, that is a sane approach, but I think it leaves too much of the
>>>> value on the floor. I often benefit from having my exhaustiveness
>>>> validated and being able to find out at compile time if things change
>>>> in the future.
>>> To be clear, I was describing:
>>>   - We'd always do exhaustiveness checking for expression switches
>>>   - A default / total pattern always implies exhaustive
>>>   - We'd additionally consider an expression switch to be exhaustive if
>>> all known enums are present _and_ the enum type is in the same module as
>>> the switch
>>>
> >> But that's probably too fussy.