Expression switch exception naming

[Brian Goetz]

Summarizing what I heard: seeing Error is your trigger to "go fix your 
classpath and recompile".  And implicitly, you're saying: if it is an 
exception (no matter how clearly worded about inconsistent assumptions 
across classes), it is far less likely to trigger this reaction?

>
>     (And, we've told people for years that its OK to add enum constants.)
>
>
> Yes, but we are deciding to reverse that decision 15 years later. 
> We're doing that because we think it's worth it, but let's at least be 
> clear about the fact that that is what we're doing.
>

Let's back up.  Are we really reversing this?   Or are we doing 
something more subtle?

Is it OK to add enum constants if they are not published across 
maintenance boundaries?
Is it OK to add enum constants if you don't use expression switches?
Is it OK to add enum constants if you use expression switches with 
explicit defaults?


Suppose you publish an API that has
     enum TrafficLight { RED, YELLOW, GREEN }

And I depend on your API with an optimistically exhaustive switch 
(OES).  Then you add BLUE**

So, who's at fault?
  - You, for adding a switch to an enum that is published across a 
maintenance boundary?
  - Me, for OESing on an enum imported across a maintenance boundary?
  - Java, for letting me OES across a maintenance boundary?

(The latter is a new idea, but I think is what you're getting at -- 
perhaps the rule should be that _within a module_, which is expected to 
be co-compiled, its OK to leave off the default, but for "foreign" 
enums/sealed types, we're not going to put any faith in the claim of 
sealed-ness, and make you handle the default explicitly?



**Note that just _adding_ an enum is not enough to trigger an error.  
Someone actually has to pass that enum to me.  And I have to switch on 
it.  And that switch has to be optimistically exhaustive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180330/749d063b/attachment.html>