Expression switch exception naming

[Brian Goetz]

> Although the depth of this debate may seem to have exceeded its value 
> in resolving the question at hand, I think it's usually worthwhile to 
> try hammer out these kinds of differences, until we all have a greater 
> common understanding (or clearly arrive at an impasse...).

Nah, I'm not grumpy yet :)

> Now, either this came to my attention through a compile-time or 
> runtime error. If the former, it is clear what is going on, and is 
> part of my normal workflow for how I get my code to work. If the 
> latter, I'm suggesting that the best thing we can do is to prompt the 
> developer to wonder "wait, why didn't I get a compile error?" so that 
> it reduces to the former.

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?

>
>
>     (The latter is a new idea, but I think is what you're getting at
>     -- perhaps the rule should be that _within a module_, which is
>     expected to be co-compiled, its OK to leave off the default, but
>     for "foreign" enums/sealed types, we're not going to put any faith
>     in the claim of sealed-ness, and make you handle the default
>     explicitly?
>
>
> I'm not sure I understand this, and therefore I suspect it's not what 
> I'm getting at. :-)

Expanding:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180330/37ba406d/attachment.html>