[pattern-switch] Exhaustiveness

[forax at univ-mlv.fr]

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "daniel smith" <daniel.smith at oracle.com>
> Cc: "Guy Steele" <guy.steele at oracle.com>, "Remi Forax" <forax at univ-mlv.fr>,
> "Tagir Valeev" <amaembo at gmail.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Envoyé: Lundi 31 Août 2020 17:09:35
> Objet: Re: [pattern-switch] Exhaustiveness

> To be clear, I think the sweet spot here is:

> - Legacy enum, string, and box (ESB) switches continue to throw NPE on null;
> - Total switches on enum (including the current expression switches on enum)
> throw ICCE on a novel value;
> - For new switches with remainder:
> - Continue to throw NPE on unhandled null remainder;
> - Throw UnexpectedFrogException on any other unhandled remainder.
I read this as ICCE not being good enough compare to UnexpectedFrogException and i don't understand why ? 

Rémi 

> On 8/28/2020 9:18 PM, Brian Goetz wrote:

>>> And for all this complex analysis we get... some different exception types?
>>> Doesn't seem like a worthwhile trade.

>> As I've mentioned already, I think the exception-type thing is mostly a red
>> herring. We have some existing precendent, which is pretty hard to extrapolate
>> from:

>> - Existing switches on enum/string/boxes throw NPE on a null target;
>> - (As of 12) enum expression switches throw ICCE when confronted with a novel
>> value.

>> All the discussion about exception types are trying to extrapolate from these,
>> but it's pretty hard to actually do so. I would be happy to just have some sort
>> of SwitchRemainderException.

>>> What I'd like to do instead: switch expressions that are optimistically/weakly
>>> total get an implicit 'default' case that throws 'UnmatchedSwitchException' or
>>> something like that for *everything* that goes unhandled. Exactly what
>>> diagnostic information we choose to put in the exception is a quality of
>>> implementation issue. As a special case, if the unmatched value is 'null' (not
>>> 'Box(null)'), we *might* decide to throw an NPE instead (depending on how your
>>> ideas about null hostility in switches pan out)

>> That is, essentially, what I have proposed in my "Totality" thread (I suspect
>> you're still catching up, as it took us a long time to get there.)

>>> This is a behavioral change for enum switch expressions in Java 14+ code, which
>>> makes me feel a bit sheepish, but I don't think anybody will mind a change now
>>> that the design has evolved enough to recognize the need for a specific
>>> exception class.

>> I don't think we need an incompatible change; we're already sealing off some
>> legacy behavior with enum/string/box switches, we can seal this one off there
>> too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200831/51920124/attachment.htm>