Given that you can explicitly add a default target, it's an opt-in mechanism, if you add you own 'default' target, you explicitly say how you want to recover to an enum constant you do not known.
Using a runtime exception is like another less readable way to do exactly that. Rémi ----- Mail original ----- > De: "Brian Goetz" <[email protected]> > À: "Remi Forax" <[email protected]>, "Gavin Bierman" > <[email protected]> > Cc: "amber-spec-experts" <[email protected]> > Envoyé: Mercredi 28 Mars 2018 17:51:43 > Objet: Re: Expression switch exception naming >> NoCaseMatchError (or any other name) which is a subtype of >> IncompatibleClassChangeError. > > I buy the "subtype of ICCE" argument, but it seems to me these need to > be exceptions, not errors. (Thought experiment: if we already had both > ICC{Exception,Error}, would we have jumped so fast to Error? I don't > think so.) I'd support adding ICEException and having these be subtypes. > > Adding a new enum value is not the same sort of obviously-incompatible > change as changing a static method to instance, or a concrete method to > abstract, which are the sorts of things that trigger ICCError. > > On the naming front, I would think this is more in the category of > "unexpected class change exception" than "incompatible change." Adding a > new enum constant isn't intrinsically evil. If anything, the issue is > on the client, who relied on the assumption of of exhaustiveness.
