Expression switch exception naming

Brian Goetz brian.goetz at
Thu Apr 19 21:50:19 UTC 2018

I like Un{recognized,known}EnumConstantE{rror,xception}.  When we get to 
sealed types, it will be the same but with something like 

I am still having trouble squaring the Error vs Exception, but you've 
pulled me from "seems like an Exception to me" into "crap, now I don't 
know" territory :)

I think what makes me uncomfortable is that there are some enums that 
are _intended_ to be extended, such as 
java.lang.annotation.ElementType.  (In fact, we might be adding a new 
member soon; RECORD_COMPONENT.)  And I would want clients of ElementType 
to be aware that they never know all the element types, and code 

Which suggests that enums needs a mechanism to either mark them as 
sealed (which turns on the enhanced exhaustiveness behavior) or as 
non-sealed (which would turn it off).

On 4/19/2018 5:43 PM, Kevin Bourrillion wrote:
> Necromancing, since I noticed that the spec still contains a hole 
> where this name would go.
> *Name:*
>   * I think something specific like
>     UnexpectedEnumConstantE{rror,xception} would seem the right way to
>     go. (Perhaps "Unrecognized"?)
> *Hierarchy: *
>   * It will want a common supertype it can share with the future
>     "unexpected subtype of sealed type" error/exception.
>   * As for where that supertype goes, I still maintain that this is
>     /exactly/ an IncompatibleClassChangeError (argument below), and
>     thus should be a subtype of that. I also see nothing harmed by it
>     being an Error instead of Exception.
> My claim is that releasing an enum with a certain set of constants is 
> qualitatively equivalent to releasing an interface with a certain set 
> of abstract methods. We know that people key behavior off of enums 
> (that's what enum switch is all about). That means that when we add a 
> constant, we are adding new /contract/, which we (the enum owners) 
> don't know how to fulfill. The call sites need to fulfill it.
> Thought experiment: I can already implement an interface in two 
> different ways: the normal way, or via a dynamic proxy that throws an 
> exception if it gets an unexpected method. Let's imagine that the 
> latter way was made exactly as easy to express as the former. I think 
> everyone would probably agree that most implementations would 
> /still/ choose the current behavior. (Yes?) They don't /want/ anything 
> to fail at runtime that could instead fail at compile-time.
> Anyway, all of this is just to support the notion that this should be 
> an IncompatibleClassChangeError. Of course, the argument's been made 
> in this thread that it /is/ different from an incompatible class 
> change. My response was that these reasons seem way too subtle to me. 
> Or, have I been persistently missing something?
> On Fri, Mar 30, 2018 at 11:31 AM, Kevin Bourrillion <kevinb at 
> <mailto:kevinb at>> wrote:
>     On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz
>     <brian.goetz at <mailto:brian.goetz at>> wrote:
>         Backing way up, Alex had suggested that the right exception is
>         (a subtype of) IncompatibleClassChangeEXCEPTION, rather than
>         Error.  I was concerned that ICC* would seem too low-level to
>         users, though.  But you're saying ICCE and subtypes are
>         helpful to suers, because they guide users to "blame your
>         classpath".  SO in that case, is the ICC part a good enough
>         trigger?
>     (Just to be clear, Remi and I have been advocating for a subtype
>     of ICC*Error* all along, in case anyone missed that.)
>     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}?
>         For an enum in the same class/package/module as the switch,
>         the chance of getting the error at runtime is either zero
>         (same class) or effectively zero (same package or module),
>         because all sane developers build packages and modules in an
>         atomic operation.
>         For an enum in a different module as the switch, the chance of
>         getting the error at runtime is nonzero, because we're linking
>         against a JAR at runtime.
>         So an alternative here is to tweak the language so that the
>         "conclude exhaustiveness if all enum constants are present"
>         behavior should be reserved for the cases where the switch and
>         the enum are in the same module?
>         (Just a thought.)
>     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.
>     -- 
>     Kevin Bourrillion | Java Librarian | Google,
>     Inc. |kevinb at <mailto:kevinb at>
> -- 
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at 
> <mailto:kevinb at>

More information about the amber-spec-observers mailing list