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