Expression switch exception naming

Kevin Bourrillion kevinb at google.com
Fri Apr 20 18:06:29 UTC 2018


That's useful information, Dan, and I agree that it is unsurprising. To
keep harping on the comparison to interface methods, it has been just the
same with them. Many interfaces have been natural candidates to grow over
time, and it was a bummer that they couldn't. (Then in 8 they acquired a
way to attach their own default behavior, but there the analogy runs out of
gas - enums could never really have that.)

But here's the thing. For those sealed enums that never grow, this whole
feature never really has that much value anyway. All it accomplishes is
that it helps me avoid a simple mistake of leaving one off, and lets me
skip an annoying pointless `default:`.

What it does for the enum that grows is so much more valuable: I gain the
opportunity to fix my code to do the right thing, before it fails at
runtime. That's a good thing.

I'm beginning to feel more convinced that the least-bad solution is just to
massage the definition of what source compatibility really means. Because
we can consider this breakage to be "opt-in", a project that commits to
compatibility should *still* be free to grow any enum. And I don't think we
even need a sealed distinction.



On Fri, Apr 20, 2018 at 10:26 AM, Brian Goetz <brian.goetz at oracle.com>
wrote:

> I am totally unsurprised to see this observation.  And, I also think that
> if we did declare some of them sealed, on the basis of being unable to
> imagine that more would be added, we'd be wrong as often as right, other
> than the obvious extremes of Month and ElementType. Which puts us in a bind.
>
> That said, in light of the recent leap from UA1 to UA2, I am starting to
> question the wisdom of assuming that an enum is sealed. In light of
> morning, it feels more in the category of "picking winning idioms" rather
> than composing behavior from first principles.
>
> Right.  I think there are two kinds of enums, call them sealed and
>>> unsealed,
>>>
>> 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.
>>
>>
>


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com


More information about the amber-spec-observers mailing list