On Mar 28, 2018, at 12:48 PM, Brian Goetz <brian.go...@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
