Expression switch exception naming

[Remi Forax]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Kevin Bourrillion" <kevinb at google.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Vendredi 30 Mars 2018 19:48:03
> Objet: Re: Expression switch exception naming

>> 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.)
Not having the same behavior due to a refactoring that introduces an intermediary module seems a big no no for me. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180330/ee2d5967/attachment-0001.html>