Expression switch exception naming
Brian Goetz
brian.goetz at oracle.com
Fri Apr 20 17:50:33 UTC 2018
> So I buy Brian's argument that this is not an Error but a RE.
> I bought it on a hunch, and the above reasoning seems to
> bear it out under morescrutiny.
>
After further discussion, the Error-vs-Exception debate here was really
a proxy for a more important question, which is: are we justified in
assuming that enums are effectively sealed, and using that in the
semantics of switch. So far none of the answers are all that great.
Clearly, we're not adding any more booleans, so a switch that covers
true and false is exhaustive. We're pretty comfortable with the idea
that boolean is sealed. (You could make the same argument for byte.)
For an explicitly sealed type, I buy it's an ICCE when an unexpected
subtype shows up. The author said "these are the only three subtypes",
so a fourth is definitely cause for worry that your configuration is
borked.
Enums are in the middle. We'd like to behave as if they're sealed, but
they're not, and for some enums, they really are intended to be not
sealed. (The "language version" enum in javax.lang.model or the API
version enum in ASM are obvious examples.)
Here's an idea that was pretty unpopular when I first brought it up, but
now that people see the problem more, might offer more light on the
problem, which is, to consider boundaries.
If I have a class:
class C {
enum E { A,B; }
... switch (e) ...
}
its pretty clear that a switch that covers A and B is exhaustive; I
can't add cases without recompiling C. Here, the user would surely want
us to infer sealed-ness for E.
If I have two classes in the same _package_ ... can I make the same
assumption? I think so. Packages are intended to be compiled as a
unit. In fact, _modules_ are intended to be compiled as a unit. The
assumption of sealed-ness for enums used within a package or module is
pretty reasonable.
Its when we get to uses across module boundaries that inferring
sealed-ness in the absence of an explicit annotation to that effect is
questionable.
Now, no one is comfortable with the idea of using package or module
boundaries here, but ultimately, the problem is that the validity of the
assumption of sealed-ness is dependent on boundaries.
More information about the amber-spec-experts
mailing list