Expression switch exception naming

forax at forax at
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.


----- Mail original -----
> De: "Brian Goetz" <brian.goetz at>
> À: "Remi Forax" <forax at>, "Gavin Bierman" <gavin.bierman at>
> Cc: "amber-spec-experts" <amber-spec-experts at>
> 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