Exhaustiveness in switch

[Brian Goetz]

> * 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 to faraway arguments. (Okay: one 
> reason might be if your message is long enough that you'd like to use 
> a multi-line raw string literal for it, where concatenation is 
> BadBadBad, but I can't say how common this is or isn't at the moment.)

I think this is YMMV.  Some users (this one included) always feel dirty 
using string concatenation.  I would prefer to use formatting almost all 
the time.  That exceptions don't incorporate formatting is mostly an 
artifact of the fact that the last big overhaul in exception APIs was in 
1.4 (when we added chaining) and format was added in 1.5.  (Because of 
the way it was done in 1.4, where the constructor parameter of the 
general form is (String, Throwable), we can't overload with a (String, 
Object...) constructor that would treat the string as a format string, 
which is surely what we would have done had we had format() in 1.0.)

> * I think that for most occurrences of `default: throw...`, by far, 
> the user really doesn't benefit from being able to choose the 
> exception type or the message at all. A standardized choice of 
> exception, and an autogenerated message (that automatically includes 
> the switch target, which users usually don't bother to do 
> themselves!), may be strictly better. Can we consider providing them a 
> shortcut (strawman: just `default: throw;`!)?

We did actually discuss this very notion.  While its attractive, it also 
feels like an attractor for an infinite stream of "can you let me 
customize x/y/z" requests.  So we wanted to explore whether there are 
library moves we can make that get us to this benefit first. For 
example, if you could say

     default: throw switchException();

where switchExpression() was a static-import of 
Intrinsics.switchExpression() (which could still capture 
Object.toString() of the target, as well as a description of the switch 
context), that's a smaller hammer with more flexibility.

> * For exhaustive switches (so far: enums), the ideal we have been 
> trying to shoot for is that the user makes an informed, intelligent 
> choice about whether they want the compile error or the runtime error 
> when a new one is added. So far, with what we've implemented at 
> Google, it seems that we're falling fall short of that ideal. We have 
> been strongly considering the idea that you /shouldn't/ be allowed to 
> simply omit a default at all, because what that /means/ is far too 
> opaque. It would be better if the user had to do something explicit in 
> either case. Could it be that the idea in the previous bullet actually 
> provides this? We would go back to always requiring an explicit 
> `default` for an e-switch, but you still get to make an explicit 
> choice which behavior you're asking for.

That sounds like a turnaround.  Previously, you'd argued that specifying 
all the enum cases and omitting a default was ideal because then you 
have a valuable tripwire against new values being added without them 
getting swept under the rug.

> * It would feel strange to even bother applying this exhaustiveness 
> goo to /byte/ switches. If we ever had ranges.... of course then, any 
> type of switch could join the party. (I don't know whether ranges are 
> a thing we're considering or not and I'm not pushing that we do.)

Yeah, its on the edge.  Its a no-brainer for `boolean`, its nuts for 
`int` (without ranges), but its vaguely defensible for `byte`. Though I 
can't really get too excited about it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180510/6e18ea84/attachment.html>