[pattern-switch] Exhaustiveness

[Brian Goetz]

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.



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/15301c7d/attachment.htm>