Re: Exhaustiveness in switch

- Mail original - > De: "Brian Goetz" <brian.go...@oracle.com> > À: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 10 Mai 2018 22:12:37 > Objet: Exhaustiveness in switch > In the long (and indirect) threa

Re: Exhaustiveness in switch

> De: "Kevin Bourrillion" <kev...@google.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 10 Mai 2018 22:44:33 > Objet: Re: Exhaustiveness in s

Re: Exhaustiveness in switch

OK, but consider these cases. Case 1:     enum E { A, B }     ...     switch (e) {     case A -> ...     case B -> ...     default: throw ...;     } Now, we add "C" to E and recompile.  No compilation error, and it throws on input C. Case 2:     enum E { A, B }     ...    

Re: Exhaustiveness in switch

> On May 10, 2018, at 2:46 PM, Guy Steele wrote: > >> On May 10, 2018, at 4:54 PM, Brian Goetz > > wrote: >> >>> * It would feel strange to even bother applying this exhaustiveness goo to >>> byte switches. If we

Re: Exhaustiveness in switch

* Users of Guava's Preconditions love the support for "%s"-formatting.  But on the other hand, in code where you /are definitely/ about to throw something, why wouldn't I just use string concatenation? That is generally easier to read because you don't have to mentally correlate specifiers

Re: Exhaustiveness in switch

This is just a quick initial response and that it will veer off-topic: * Users of Guava's Preconditions love the support for "%s"-formatting. But on the other hand, in code where you *are definitely* about to throw something, why wouldn't I just use string concatenation? That is generally easier

Exhaustiveness in switch

In the long (and indirect) thread on "Expression Switch Exception Naming", we eventually meandered around to the question of when should the compiler deem an expression switch to be exhaustive, and therefore emit a catch-all throwing default. Let's step back from this for a bit and remind