Expression switch exception naming

Kevin Bourrillion kevinb at
Thu Apr 19 21:43:30 UTC 2018

Necromancing, since I noticed that the spec still contains a hole where
this name would go.


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

> On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz <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

Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at

More information about the amber-spec-observers mailing list