Expression switch exception naming

Brian Goetz brian.goetz at
Fri Mar 30 18:39:30 UTC 2018

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

More information about the amber-spec-experts mailing list