[pattern-switch] Exhaustiveness

Brian Goetz brian.goetz at oracle.com
Sat Aug 29 01:18:35 UTC 2020


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




More information about the amber-spec-experts mailing list