Expression switch exception naming
Brian Goetz
brian.goetz at oracle.com
Fri Mar 30 20:17:35 UTC 2018
> It's not clear to me what the utility of nominally always having an
> exhaustiveness check would be if I end up having to include a "default"
> everywhere anyway. If someone adds an enum constant (and I'm compiling
> my code against their new code), I want to get compilation errors in
> every switch that now needs to be updated. If I have to add a "default"
> everywhere in the source, I won't get that (and will have to hope that
> my test coverage is good enough to find all the switches that are now
> incorrect).
OK, we have a terminology confusion over the term "exhaustiveness
checking." I meant that the compiler won't let you write an
inexhaustive switch expression (which, for almost all target types, will
require a default/total pattern), even though it will let you for switch
statements (in the absence of flow constraints to the contrary, such as
a blank local.)
> My understanding to date has been that a "default" wasn't going to be
> required for enum and sealed types, and that if I didn't provide one,
> the compiler would synthesize one that raises an exception... Now
> things seem to have shifted somewhat.
They haven't shifted; I was describing this option as a means of getting
at Kevin's distinction about classpath dependencies. Within a
maintenance domain, you basically never have to worry about your enums
and switches over those enums getting out of sync; across maintenance
domains, you do. So the question was, should we consider treating
cross-module "hope nothing changes between now and runtime" assumptions
more skeptically. It was a thought experiment, not a proposal, aimed at
closing the loop (since this thread has had an awful lot of
talking-past-each-other.)
> I configure my IDE to refuse to allow me to use default on enum
> switches, and to treat missing cases as a compilation error:
>
> switch (e) {
> case RED: ...
> case YELLOW: ...
> case GREEN: ...
> }
> throw new UnreachableCodeException();
We'd not do anything for switch statements. Exhaustiveness checking is
only for switch expressions in any case.
But, your point is taken; *not* having a default in a situation that
requires exhaustiveness acts as a type-check on that exhaustiveness, and
saying default will then cover up any sins. I get it.
More information about the amber-spec-experts
mailing list