Expression switch exception naming

[Mark Raynsford]

On 2018-03-30T15:10:32 -0400
Brian Goetz <brian.goetz at oracle.com> wrote:

> Yes, you misunderstood :)
> 
> You would always get an exhaustiveness check.  What you'd not get is the 
> "grace" of having said:
> 
>     case RED:
>     case YELLOW:
>     case GREEN:
> 
> without a default, and having that still be considered exhaustive 
> because these are all the alternatives known at compile time.  It would 
> be like today, where flow analysis sometimes requires you to have a 
> default on an enum switch even though you've covered all the bases.

There's a subtlety to the language here that I think might be throwing
me off.

It's not clear to me what the utility of nominally always having an
exhaustiveness check would be if I end up having to include a "default"
everywhere anyway. If someone adds an enum constant (and I'm compiling
my code against their new code), I want to get compilation errors in
every switch that now needs to be updated. If I have to add a "default"
everywhere in the source, I won't get that (and will have to hope that
my test coverage is good enough to find all the switches that are now
incorrect).

My understanding to date has been that a "default" wasn't going to be
required for enum and sealed types, and that if I didn't provide one,
the compiler would synthesize one that raises an exception... Now
things seem to have shifted somewhat.

I configure my IDE to refuse to allow me to use default on enum
switches, and to treat missing cases as a compilation error:

    switch (e) {
      case RED: ...
      case YELLOW: ...
      case GREEN: ...
    }
    throw new UnreachableCodeException();

I don't specify a default, so the code raises UnreachableCodeException
if someone makes a binary-incompatible change and I've not recompiled,
and the IDE/compiler tells me if someone added an enum constant that
I've not handled by refusing to compile my code.

-- 
Mark Raynsford | http://www.io7m.com