Expression switch exception naming
cushon at google.com
Fri Mar 30 16:05:59 UTC 2018
On Fri, Mar 30, 2018 at 8:35 AM Brian Goetz <brian.goetz at oracle.com> wrote:
> I think we are the heart of the disagreement. I do not think that
> "someone added an enum constant" is necessarily a classpath insanity
> thing. Its just as likely to be a garden-variety "you made one assumption
> over here and another over there" within the same codebase. (And, we've
> told people for years that its OK to add enum constants.)
Won't the garden-variety differences in assumptions normally be reported at
compile-time? If the codebase is recompiled after the enum is updated, I
would expect javac to reject an e-switch over an enum type that does not
explicitly handle all enum constants and omits an explicit default case.
For the exception being discussed to be thrown, the enum has to change
after the code switching on it has been compiled, and then the switch has
to be executed without having been recompiled. That skew between the
classpath the switch was compiled against and the classpath the switch runs
against is the 'classpath insanity' part.
> I think its at least as likely that this is in the same category as any
> other assumption we make about code we call. Like "this method never
> returns null". Or "this method says it returns Object, but I know it
> always returns String, so I'll cast to String."
I see a distinction here in that there's no way to enforce those other
assumptions at compile-time.
More information about the amber-spec-observers