Expression switch exception naming

[Kevin Bourrillion]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180330/b777458f/attachment.html>