What is the usage of default when the switch is for an enum?

Question

Suppose I have an enum Color with 2 possible values: RED and BLUE:

public enum Color {
    RED,
    BLUE
}

Now suppose I have a switch statement for this enum where I have code for both possible values:

Color color = getColor(); // a method which returns a value of enum "Color"
switch (color) {
case RED:
   ...
   break;

case BLUE:
   ...
   break;

default:
   break;
}

Since I have code block for both possible values of the enum, what is the usage of default in the above code?

Should I throw an exception if the code somehow reaches the default block like this?

Color color = getColor(); // a method which returns a value of enum "Color"
switch (color) {
case RED:
   ...
   break;

case BLUE:
   ...
   break;

default:
   throw new IllegalArgumentException("This should not have happened");
}

Say you add a new Color like GREEN without changing the code? — Peter Lawrey, Oct 08 '15 at 15:12
At least there would be a compiler warning if a new enum is added which does not have a case. — wero, Oct 08 '15 at 15:13
Does Java enforce that an enum value _must be_ a member of the enum? Because C++ doesn't and I've seen that confuse people in switch or if/else statements. — JPhi1618, Oct 08 '15 at 19:02
@JPhi1618 Yes, every Java enum is basically a class (subclassed from `Enum`) with some syntactic sugar that provides a specific set of instances accessible from the class. — JAB, Oct 08 '15 at 21:18
I've never seen a compiler warning when not including every value of an enum in a switch statement. — Zymus, Oct 08 '15 at 23:31
@JPhi1618 It's *possible* to do some very dodgy things with reflection to create a new value at runtime. But more importantly, it's possible to add a new value to the enum, and recompile the enum without recompiling the class containing the switch statement, and that is not an unusual scenario. — user253751, Oct 09 '15 at 11:26
Possible duplicate of [Why is default required for a switch on an enum in this code?](http://stackoverflow.com/questions/5013194/why-is-default-required-for-a-switch-on-an-enum-in-this-code) — James_pic, Oct 09 '15 at 13:04
@Zymus Eclipse has the option to turn on compiler warnings for missing enums in a switch statement, I don't know about other IDE's. — dj18, Oct 09 '15 at 16:19
Myself I'd throw an `InvalidEnumArgumentException` if possible — AndrewD, Oct 14 '15 at 01:56

score 91 · Accepted Answer · edited Oct 08 '15 at 22:37

91

It is good practice to throw an Exception as you have shown in the second example. You improve the maintainability of your code by failing fast.

In this case it would mean if you later (perhaps years later) add an enum value and it reaches the switch statement you will immediately discover the error.

If the default value were not set, the code would perhaps run through even with the new enum value and could possibly have undesired behavior.

edited Oct 08 '15 at 22:37

Kirill Rakhman

42,195
18
124
148

answered Oct 08 '15 at 15:11

Dainesch

1,320
13
19

19

I'd usually throw an AssertionError – ZhongYu Oct 08 '15 at 15:36
3

I prefer to use an IllegalStateException – aurya Oct 14 '15 at 07:38

score 54 · Answer 2 · answered Oct 08 '15 at 16:09

The other answers are correct in saying that you should implement a default branch that throws an exception, in case a new value gets added to your enum in the future. However, I would go one step further and question why you're even using a switch statement in the first place.

Unlike languages like C++ and C#, Java represents Enum values as actual objects, which means that you can leverage object-oriented programming. Let's say that the purpose of your method is to provide an RGB value for each color:

switch (color)
    case RED:
       return "#ff0000";
    ...

Well, arguably, if you want each color to have an RGB value, you should include that as part of its description:

public enum Color
{
    RED("#FF0000"),
    BLUE("#0000FF");

    String rgb;
    public Color(String rgb) {
        this.rgb = rgb;
    }
    public getRgb() { return this.rgb; }
}

That way, if you add a new color later, you're pretty much forced to provide an RGB value. It's even more fail-fast than the other approach, because you'll fail at compile-time rather than run-time.

Note that you can do even more complicated things if you need to, including having each color provide its own custom implementation of an abstract method. Enums in Java are really powerful and object-oriented, and in most cases I've found I can avoid needing to switch on them in the first place.

It might be worthwhile if you want to take advantage of fall-through, e.g., enumerating blackjack wager outcomes (if I understand correctly, natural blackjack is unique in paying 3 to 2, but the other winning outcomes pay out the same) — Alonso del Arte, Mar 11 '23 at 04:27
@AlonsodelArte: It seems like that use case wouldn't require a switch case with a "fall-through": just make the default implementation of a method return the default payout ratio, and override it for the one exceptional case to return a 3-to-2 payout ratio. — StriplingWarrior, Mar 13 '23 at 15:21
@StriplingWarrior There's also the losing outcomes. But maybe I'll ultimately put all those on the `Outcome` enumeration rather than the `Settlement` class. Either way, it'll be an improvement over the spaghetti I wrote for the quick and dirty implementation — Alonso del Arte, Mar 14 '23 at 17:30

Tomas Pinos · Answer 3 · 2015-10-11T20:04:00.863

12

Compile time completeness of the switch cases doesn't guarantee runtime completenes.

Class with a switch statement compiled against an older version of enum may be executed with a newer enum version (with more values). That's a common case with library dependencies.

For reasons like these, the compiler considers the switch without default case incomplete.

edited Oct 11 '15 at 20:04

answered Oct 08 '15 at 15:14

Tomas Pinos

2,812
14
22

score 8 · Answer 4 · answered Oct 08 '15 at 15:10

In small programs, there is no practical use for that, but think of a complex system that speards among large number of files and developers - if you define the enum in one file and use it in another one, and later on someone adds a value to the enum without updating the switch statement, you'll find it very useful...

T.J. Crowder · Answer 5 · 2015-10-09T08:35:41.177

7

If you've covered all of the possibilities with your various cases and the default cannot happen, this is the classic use case for assertions:

Color color = getColor(); // a method which returns a value of enum "Color"
switch (color) {
    case RED:
       // ...
       break;

    case BLUE:
       // ...
       break;

    default:
       assert false; // This cannot happen
       // or:
       throw new AssertionError("Invalid Colors enum");
}

edited Oct 09 '15 at 08:35

answered Oct 09 '15 at 08:18

T.J. Crowder

1,031,962
187
1,923
1,875

2

Since assertions have to be enabled to take effect, I would argue that explicitly throwing the AssertionError is safer. – Rory Hunter Oct 14 '15 at 07:58

score 6 · Answer 6 · 2015-10-08T15:16:41.780

6

To satisfy IDEs and other static linters, I often leave the default case in as a no-op, along with a comment such as // Can't happen or // Unreachable

i.e., if the switch is doing the typical thing of handling all possible enum values, either explicitly or via fall-throughs, then the default case is probably programmer error.

Depending on the application, I sometimes put an assertion in the case to guard against programmer error during development. But this has limited value in shipping code (unless you ship with assertions enabled.)

Again, depending on the situation I might be convinced to throw an Error, as this is really an unrecoverable situation -- nothing the user can do will correct what is probably programmer error.

edited Oct 08 '15 at 15:16

answered Oct 08 '15 at 15:10

2

Linters should NOT dictate how we write code. They're meant to provide suggestions, not silver bullet standards. – Silviu Burcea Oct 09 '15 at 08:18
Satisfying the linter is a secondary issue, though. The default case is still syntactically correct, and it is up to the programmer to assert it will not, or should not, be reached. Providing a guarded default case is more about making maintainable and more robust code. Given that we code for at least two compilers, the JVM and the humans changing the code in the future, it's often more important to write code intended for the latter. It's not about getting rid of red underlines in the editor, but about maintainable code. – Oct 09 '15 at 14:49

Andrew Tobilko · Answer 7 · 2015-10-08T15:23:14.887

6

Yes, you should do it. You may change enum but don't change switch. In the future it'll lead to mistakes. I think that throw new IllegalArgumentException(msg) is the good practice.

edited Oct 08 '15 at 15:23

answered Oct 08 '15 at 15:11

Andrew Tobilko

48,120
14
91
142

score 5 · Answer 8 · answered Oct 08 '15 at 15:10

5

When the enum constants are too many and you need to handle only for few cases, then the default will handle the rest of the constants.

Also, enum constants are references, if the reference is not yet set, or null. You may have to handle such cases too.

answered Oct 08 '15 at 15:10

rajuGT

6,224
2
26
44

Can you elaborate **"Also, enum constants are references, if the reference is not yet set, or null. You may have to handle such cases too."**? Are you saying Color.RED or Color.BLUE can be null? How can it be possible? – ChumboChappati Oct 08 '15 at 15:31
It is possible. But Color.RED or Color.BLUE is not null. They are instances of Color enum. Suppose, if you declare `Color someColor;` without initializing it into any enum value constant. like, `Color someColor = Color.RED;`. using the reference someColor, you can pass it to function/method which accepts Color enum. and here in the first case it is `null` and in the second it is `Color.RED`. http://stackoverflow.com/questions/3231684/are-java-enums-considered-primitive-or-reference-types. Also, there is a base class for enum, check http://docs.oracle.com/javase/7/docs/api/java/lang/Enum.html. – rajuGT Oct 08 '15 at 15:39
3

Your wording is bad in the second paragraph. It actually does sound like you're saying `Color.RED` could be `null` instead of `Color someColor` could be null. It's because you say they're references and then say "the reference" without clear indication of talking about a different variable. You didn't *declare* it, if you will. – Captain Man Oct 08 '15 at 20:17
Yes the second statement, I got that. but when I recognize that mistake, the **edit** option of the comment wasnt there. So :( What I meant was, there can be a reference created for an enum, which can point to any of its constants or nothing i.e. `null`. I've also mentioned two other source, hope that will give clarity I feel and thanks for mentioning this too. :) – rajuGT Oct 08 '15 at 20:23
You cannot handle `null` in a switch statement. If the expression you switch on is null, it will throw an NPE. – Didier L Oct 23 '16 at 08:48

score 5 · Answer 9 · edited May 23 '17 at 12:24

5

Yes, it is dead code until someone add a value to the enum, which will make your switch statement follow the principle of 'fail fast' (https://en.wikipedia.org/wiki/Fail-fast)

This could relates to this question : How to ensure completeness in an enum switch at compile time?

edited May 23 '17 at 12:24

Community

1
1

answered Oct 08 '15 at 15:12

Thierry

5,270
33
39

score 3 · Answer 10 · answered Oct 09 '15 at 14:06

Apart from the possible future extending of the enum, which was pointed out by many, some day someone may 'improve' yout getColor() or override it in a derived class and let it return an invalid value. Of course a compiler should catch that, unless someone explicitly forces unsafe type casting...

But bad things just happen, and it's a good practice not to leave any unexpected else or default path unguarded.

score 3 · Answer 11 · answered Oct 09 '15 at 15:16

I'm surprised nobody else mentioned this. You can cast an int to an enum and it won't throw just because the value is not one of the enumerated values. This means (among other things), the compiler cannot tell that all the enum values are in the switch.

Even if you write your code correctly, this really does come up when serializing objects that contain enums. A future version might add to the enum and your code choke on reading it back, or somebody looking to create mayhem may hexedit a new value in. Either way, running off the switch rarely does the right thing. So, we throw in default unless we know better.

score 1 · Answer 12 · answered Oct 14 '15 at 10:36

Here is how I would handle it, beside NULL value which would result in a null pointer exception which you can handle.

If Color color is not null, it has to be one of the singletons in enum Color, if you assign any reference to an object that is not one of the them this will cause a Runtime error.

So my solution is to account for values that are not supported.

Test Run

Test.java

public Test
{
  public static void main (String [] args)
  {
    try { test_1(null); }
    catch (NullPointerException e) { System.out.println ("NullPointerException"); }

    try { test_2(null); }
    catch (Exception e) { System.out.println(e.getMessage()); }

    try { test_1(Color.Green); }
    catch (Exception e) { System.out.println(e.getMessage()); }
  }

  public static String test_1 (Color color) throws Exception
  {
    String out = "";

    switch (color) // NullPointerException expected
    {
      case Color.Red:
        out = Red.getName();
        break;
      case Color.Blue:
        out = Red.getName();
        break;
      default:
        throw new UnsupportedArgumentException ("unsupported color: " + color.getName());
    }

    return out;
  }

.. or you can consider null as unsupported too

  public static String test_2 (Color color) throws Exception
  {
    if (color == null) throw new UnsupportedArgumentException ("unsupported color: NULL");
    return test_1(color);
  }
}

Color.java

enum Color
{
  Red("Red"), Blue("Blue"), Green("Green");
  private final String name;
  private Color(String n) { name = n; }
  public String getName() { return name; }
}

UnsupportedArgumentException.java

class UnsupportedArgumentException extends Exception
{
  private String message = null;

  public UnsupportedArgumentException() { super(); }

  public UnsupportedArgumentException (String message)
  {
    super(message);
    this.message = message;
  }

  public UnsupportedArgumentException (Throwable cause) { super(cause); }

  @Override public String toString() { return message; }

  @Override public String getMessage() { return message; }
}

score 0 · Answer 13 · answered Oct 23 '16 at 08:12

0

In this case using Assertion in default is the best practice.

answered Oct 23 '16 at 08:12

Masum

4,879
2
23
28

What is the usage of default when the switch is for an enum?

13 Answers13

Linked