Expression switch exception naming
kevinb at google.com
Wed Mar 28 18:06:51 UTC 2018
On Wed, Mar 28, 2018 at 8:51 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> Adding a new enum value is not the same sort of obviously-incompatible
>> change as changing a static method to instance, or a concrete method to
>> abstract, which are the sorts of things that trigger ICCError. ... Adding a
>> new enum constant isn't intrinsically evil. If anything, the issue is on
>> the client, who relied on the assumption of of exhaustiveness.
Okay, this sentiment is what I'm disagreeing with.
I think that what we are doing here is turning that change (add constant to
enum) into an incompatible class change, just as much as any of the other
kinds. It's directly analogous to adding an interface method. Clients were
required to specify how to handle all the methods of that interface, but
then one more showed up, and those clients are now broken.
Users will find this counter-intuitive, but that's only because they won't
be used to it yet. They'll have to learn.
More to the point I think: the problem isn't "on" the client code; it's
having jars in your runtime classpath that are newer than the jars you
compiled against; that's always a dangerous idea and it continues to be so
here. Today, an experienced developer knows that there is a category of
Errors that, when you see them in the absence of reflection, always
implicate this kind of classpath issue. I can't see why this would not
belong in that same category.
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
More information about the amber-spec-observers