Expression switch exception naming
Kevin Bourrillion
kevinb at google.com
Thu Apr 19 21:43:30 UTC 2018
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 google.com>
wrote:
> On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz <brian.goetz at oracle.com>
> 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 google.com
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the amber-spec-observers
mailing list