> De: "Brian Goetz" <brian.go...@oracle.com> > À: "daniel smith" <daniel.sm...@oracle.com> > Cc: "Guy Steele" <guy.ste...@oracle.com>, "Remi Forax" <fo...@univ-mlv.fr>, > "Tagir Valeev" <amae...@gmail.com>, "amber-spec-experts" > <amber-spec-experts@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.
