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.