Expression switch exception naming

[John Rose]

On Mar 28, 2018, at 12:48 PM, Brian Goetz <Brian.Goetz at Oracle.COM> wrote:
> 
> Some incompatibilities are more of a fire drill than others.  Binary incompatibilities (e.g., removing a method) are harder to recover from than unexpected inputs.  Further, while there may be no good _local_ recover for an unexpected input, there often is a reasonable global recovery.  Error means "fire drill".  I claim this doesn't rise to the level of Error; it's more like NumberFormatException or NPE or ClassCastException.  

We want an unchecked throwable here.
Given that it's a judgement call to classify as Error or RuntimeException.
I agree with Brian that this condition does not rise to an error.
The Error doc implies that errors are unrecoverable, by saying
"a reasonable application should not try to catch" it.

Does this mean that REs are more catchable?  I guess, but what
an RE says (to me, at least) is that a basic operation of the JVM
or language is being used in a partial mode, an unexpected
input has been presented to the operation, and the *normal*
operation of the JVM is to reject the unexpected input.  This
is the case with CCE, NPE, ASE, and many other REs.

If you buy this, then it follows that when a programmer gets a
RE, he has a choice to (a) fix the input source, (b) extend the
operation code to handle the unexpected input value, or
(c) wrap a catch around the thing and do something semi-locally.
None of these options are appropriate to an Error.

So, a surprise enum value looks like an ICCE, yes, because
it happens only when surprise recompilations occur.  But that
doesn't mean it must be an Error, because users can make
any of the responses (a/b/c) above to it, so the mitigation
actions are characteristic of an RE.

One thing that tips the balance for me is remembering that
ICCE-like conditions can reasonably manifest as REs.  For
example, if I refactor a class in its hierarchy (akin to
changing an enum list), clients of that class might fail with
CCE as they change their view of the moved class.
Such CCEs often come from the translation strategy
of erased generics, which embodies compile time type
expectations in checkcast instructions.  It seems reasonable
to handle enum exhaustiveness (and eventually sealed
hierarchy exhaustiveness) using an RE something like CCE.

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.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180420/95c72e96/attachment.html>