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.go...@oracle.com>
À: "Kevin Bourrillion" <kev...@google.com>
Cc: "amber-spec-experts" <amber-spec-experts@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.

Reply via email to