Expression switch exception naming

[Dan Smith]

> On Apr 19, 2018, at 6:27 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> I think I do finally understand, thanks to your example, what is different between this and the previous kinds of incompatible changes. The JDK (and some libraries) makes strong promises not to break compatibility. Yet we simply can't throw up our hands and refuse to add constants to enums like ElementType. So either we need a way to mark it unsealed, or we have to do some very fiddly messaging, like "well, it's binary-compatible, and it's also source-compatible except for any breakages you opted into via defaultless switch expressions." The trouble with that being that many developers won't have actually consciously opted into it at all. But maybe that is a viable option?
> 
> Right.  I think there are two kinds of enums, call them sealed and unsealed, in their promises about how expected or unexpected new constants will be.  You’re right that either default — sealed or unsealed — has problems; if the default is sealed, then anyone who has written an intended-to-be-extended enum now has to go and mark it, and if the default is unsealed, their clients will be irritated.  And worse, many maintainers will be wrong about their intent to add new enum constants in the future.  Very few enums are as black-and-white as the extremes of `enum BOOL { TRUE, FALSE }` and `ElementType`.  
> 
> But I think there _are_ two cases, and its reasonable the language to look to a declaration-site cue as to whether to assume sealed-ness or not. (I might think differently tomorrow.)  

What I found in reviewing enums in the JDK is that it's pretty hard to find enums you can _guarantee_ will never grow. java.time.Month, sure. But what about Thread.State? StandardOpenOption? System.Logger.Level? Am I prepared to guarantee that we'll never have a reason to add another case?

So some sort of declaration-site feature would, I fear, either get little use or be routinely ignored when changes must be made.

—Dan