Expression switch exception naming

[Brian Goetz]

ICCE indicates that a _binary incompatible_ change was detected, which 
by definition the client cannot recover from.  Adding an enum constant 
is not a binary incompatibility (though removing one is).  
(Interestingly, neither is changing an enum to a class, if you have 
static fields for all the constants -- I learned this recently.)

However, adding an enum constant is a potential _behavioral_ 
incompatibility -- specifically, it could cause exceptions like this to 
be thrown under some circumstances.  And it is only potential because in 
order to have a problem, both the enum and the client must each bring a 
piece of the responsibility -- it is something the client could recover 
from it if it wished (by having a default).  This is an incompatibility, 
but also substantially less severe in a few ways than deleting a 
method.  (Maybe its like a method starting to return null where it never 
had before.)

If a client has a default in their switch, there's no problem.  If a 
client doesn't have a default, but provides all the known items, the 
compiler builds in a default that throws, to prevent it from being 
silently ignored.  That's all good, and things are blowing up in the 
right place with an informative message.  The behavior incompatibility 
is an interaction between the enum and the client's use of that enum.  
So I think the exception should point as much to the client as the enum.

A concrete proposal:

     UnexpectedClassChangeException <: RuntimeException
     UnexpectedSwitchTarget <: UCCE  // works both for enum and sealed 
classes







On 3/28/2018 2:06 PM, Kevin Bourrillion wrote:
> On Wed, Mar 28, 2018 at 8:51 AM, Brian Goetz <brian.goetz at oracle.com 
> <mailto: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 
> <mailto:kevinb at google.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180328/295da58b/attachment.html>