[switch] Status of implementation of switch expression
john.r.rose at oracle.com
Tue Feb 27 22:23:01 UTC 2018
On Feb 27, 2018, at 1:30 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> (Some have questioned whether inserting the throwing default automatically is wise, but I like the fact that it amounts to an assertion that "these are all the enum constants in type E", and getting an exception when that assumption is seen to be violated.)
+100 the exception is the right response to an event at runtime that
was not supposed to happen at compile time. (I assume the user
*must* mention all the enums present statically at compile time,
> However, some may not like the user of AssertionError; perhaps we need to invent a new exception type. Bikeshed away....
We have two ways to signal that something is not right in code.
ICCE and its subclasses are LinkageErrors which signal that some
feature of the class and API hierarchy is different at runtime than
it was at compile time. It covers missing fields and methods,
while missing or malformed class files are covered by siblings
of ICCE (under LE).
Meanwhile, if there is a dynamic data-dependent condition
which is thought to be unlikely but must be reported with an
exception, we often use a RuntimeException, such as NPE,
CCE, ASE, IAE. Note that EnumConstantNotPresentException,
is thrown by annotation processing.
(As a third case, unexpected data-dependent conditions are
also reported by AssertionError (a subtype of Error), which
is neither ICCE/LE nor RE. But I think the main choice is
between those two.)
It feels like we *could* have a special subtype of ICCE to
signal that a previously unknown enum has appeared
in the implicit default of a switch-over-enum.
But maybe we are also looking for a way to diagnose a
more general condition, which is "switch cases which
appeared complete at compile time are incomplete at
run time". This feels more like RE instead of ICCE,
since RE handles miscellaneous data dependent errors
which are not directly tied to shifting APIs.
If we could prove that all such incomplete switches are
the results of sihfts to API hierarchies after static compilation,
that would be an argument in favor of ICCE.
EnumConstantNotPresentException is a small argument
in favor of RE.
Bottom line: unless we can tie switch coverage errors closely
to API structure, I think we need a new RE named, roughly,
More information about the amber-dev