Expression switch exception naming

Mark Raynsford mark at
Fri Mar 30 20:07:11 UTC 2018

On 2018-03-30T15:10:32 -0400
Brian Goetz <brian.goetz at> 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

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 |

More information about the amber-spec-experts mailing list