Expression switch exception naming

forax at univ-mlv.fr forax at univ-mlv.fr
Wed Mar 28 18:48:24 UTC 2018


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" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> 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.


More information about the amber-spec-experts mailing list