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 ourselves why we care about this.
Superficially, having to write a throwing default for a condition we
believe to be impossible is annoying:
switch (trafficLight) {
case RED -> stop();
case GREEN -> driveFast();
case YELLOW -> driveFaster();
default -> throw new ExasperationException("No, we haven't
added any new traffic light colors since the invention of the
automobile, so I have no idea what " + trafficLight + " is");
}
The annoyance here, though, is twofold:
- I have to write code for something which I think can't happen;
- That code is annoying to write.
In the above, we "knew" another traffic light color was impossible, and
we listed them all -- and the compiler knew it. This is particularly
irritating. However, we often also see cases like this:
void processVowel(letter) {
switch (letter) {
case A: ...
case E: ...
case I: ...
case O: ...
case U: ...
default: throw new IllegalStateException("Not a vowel: " +
letter);
}
Here, the annoyance is slightly different, in that I could not
reasonably expect the compiler to know I'd covered all the vowels. In
fact, I think the explicit exception in this case is useful, in that it
documents an invariant known to the programmer but not captured in the
type system. But it is still annoying that I have to construct a format
string, construct an exception, and throw it; if there were easier ways
to do that, I might be less annoyed. Without diving into the bikeshed,
maybe this looks something like:
default: throw IllegalStateException.format("Not a vowel: %s",
vowel);
The details aren't relevant, but the point is: maybe a small-ish library
tweak would reduce the annoyance of writing such clauses. (This one
isn't so bad, but Dan excavated a bunch that were way worse.) But,
let's set this aside for a moment, and return back to the point of why
we want the compiler to provide a throwing default.
I think most of the discussion has centered on the problem of a novel
value showing up at runtime. This is surely an issue, and must be dealt
with, but the central issue is: a default is never able to distinguish
between a runtime-novel value and a value we just forgot to include at
compile time. It doesn't matter whether this default throws (as the
implicit default in an expression switch) or does nothing (as the
implicit default in statement switches today does).
We agreed that we should not require the user to provide a default when
they provide case clauses that cover the target type as of compile time
(true+false for boolean, all the members of a sealed type, etc.) This
is because the default you'd be forced to put in otherwise (for
expression switches) is actually harmful; if the type were later
modified to have more values, an explicit default would swallow them,
rather than yielding an error at recompilation time. So it is not only
annoying, but actually could cover up errors.
We then went off on the wrong tangent, though, where we wondered whether
it was OK to implicitly assume enums were sealed, since some enums are
clearly intended to acquire new values. But the mistake was focusing on
the wrong aspect of sealed-ness (the statement of intent to not add more
values), rather than the compiler's ability to reason credibly about
known possible values.
So, backing up, I think we should always treat a "complete" enum
expression switch specially -- don't require a default, and implicitly
add a throwing one, if all the cases are specified. This way, if the
assumption that you've covered all the cases is later broken via
separate compilation, on recompilation, you'll discover this early,
rather than at runtime. (You'll still get runtime protection either
way.) Regardless of whether we think the enum will be extended in the
future or not. There's no need for enums to declare themselves "sealed"
or "non-sealed" (and such a declaration would likely be incorrect
anyway, as it asks users to predict the future, which is error-prone.)
Given this, I'm willing to use ICCE as a base type for the implicit
exception (though there should be more specific subtypes.)
Now, statement switches. It seems sad that we can't get the same kind
of compile-time assistance over statement switches than we do over
expression switches. We're somewhat locked in by compatibility here;
statement switches today get an implicit "default: nothing" clause if
they have no default, and we cannot (and don't want to) break this. So
the next best thing is if the user could say "I want to get the same
sort of compile-time verification of putative exhaustiveness for this
statement switch as I would for expression switches." This would
require some additional syntax (please, let's not bikeshed this until
everything else on this topic is nailed down; this is a target of
opportunity, not a problem to be solved Right Now.)
Someone is likely to suggest that we should do the exhaustiveness thing
for all three of the four new forms (statement arrow, and expression
colon/arrow). Feel free to make this suggestion, but you're going to
get the "snitch" lecture :)
Another thing that we can do to make it easier to write throwing
defaults: lean on intrinsics. Recall that separately, we've got a story
to expose some compiler intrinsics for ldc() and invokedynamic().
There's room to add other things to this, such as the equivalent of
__LINE__ and __FILE__ macros in C, or (relevant to this) information
about the the current point in the compilation (such as the cases
enumerated in the innermost switch.) So for example:
default: throw SwitchException.format("Found %s, but expected one
of %s",
target,
Intrinsics.switchCases());
or even
default: throw SwitchException.of(target, Intrinsics.switchCases());
where `Intrinsics.switchCases()` would evaluate to a string that
includes all the cases handled by the current switch (in our vowels
case, this would be "A, E, I, O, U"). Again, not something for Right
Now, but something that machinery that's in the pipeline can contribute
to making it simpler and more uniform to express catch-all defaults, and
thereby reduced the perceived annoyance.
Summary:
- For switches over any type where the compiler can enumerate the
possibilities (includes enums, some primitives, and sealed types),
always allow the user to leave off a default if they've specified all
the known cases.
- Use subtypes of ICCE in implicit throwing defaults.
- Consider library enhancements to common exceptions (and maybe
additional intrinsics) to simplify code that throws formatted exceptions.
