On Fri, Mar 30, 2018 at 10:48 AM, Brian Goetz <brian.go...@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. | kev...@google.com
