Expression switch exception naming

[Remi Forax]

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.