48. Using yield in switch expressions
In Java Coding Problems, First Edition, Chapter 2, Problems 55-57 we covered in detail the new switch expressions introduced in JDK 12. It will not be fair to repeat here the content of those problems, so we continue from where we left off with the switch evolution in JDK 13+. So, Java SE 13 added the new yield statement that can be used instead of the break statement in switch expressions.We know that a JDK 12+ switch expression can be written as follows:
return switch (playerType) {
case TENNIS->
new TennisPlayer();
case FOOTBALL->
new FootballPlayer();
…
};
Moreover, we know that a label’s arrow can point to a curly-braces block as well (this works only in JDK 12, not in JDK 13+):
return switch (playerType) {
case TENNIS -> {
System.out.println(“Creating a TennisPlayer …”);
break new TennisPlayer();
}
case FOOTBALL -> {
System.out.println(“Creating a FootballPlayer …”);
break new FootballPlayer();
}
…
};
Since break can be confusing because it can be used in old-school switch statements and in the new switch expressions, JDK 13 added the yield statement to be used instead of break. The yield statement takes one argument representing the value produced by the current case. The previous examples can be written from JDK 13+ as follows:
return switch (playerType) {
case TENNIS:
yield new TennisPlayer();
case FOOTBALL:
yield new FootballPlayer();
…
};
return switch (playerType) {
case TENNIS -> {
System.out.println(“Creating a TennisPlayer …”);
yield new TennisPlayer();
}
case FOOTBALL -> {
System.out.println(“Creating a FootballPlayer …”);
yield new FootballPlayer();
}
…
};
In other words, starting with JDK 13+, a switch expression can rely on yield but not on break, and a switch statement can rely on break but not on yield.
49. Tackling the case null clause in switch
Before JDK 17 a null case in a switch was commonly coded as a guarding condition outside the switch as in the following example:
private static Player createPlayer(PlayerTypes playerType) {
// handling null values in a condition outside switch
if (playerType == null) {
throw new IllegalArgumentException(
“Player type cannot be null”);
}
return switch (playerType) {
case TENNIS -> new TennisPlayer();
case FOOTBALL -> new FootballPlayer();
…
};
}
Starting with JDK 17+ (JEP 427), we can treat a null case as any other common case. For instance, here we have a null case that is responsible to handle the scenarios when the passed argument is null:
private static Player createPlayer(PlayerTypes playerType) {
return switch (playerType) {
case TENNIS -> new TennisPlayer();
case FOOTBALL -> new FootballPlayer();
case SNOOKER -> new SnookerPlayer();
case null -> throw new NullPointerException(
“Player type cannot be null”);
case UNKNOWN -> throw new UnknownPlayerException(
“Player type is unknown”);
// default is not mandatory
default -> throw new IllegalArgumentException(
“Invalid player type: ” + playerType);
};
}
In certain contexts, null and default has the same meaning, so we can chain them in the same case statement:
private static Player createPlayer(PlayerTypes playerType) {
return switch (playerType) {
case TENNIS -> new TennisPlayer();
case FOOTBALL -> new FootballPlayer();
…
case null, default ->
throw new IllegalArgumentException(
“Invalid player type: ” + playerType);
};
}
Or if you find it more readable like this:
…
case TENNIS: yield new TennisPlayer();
case FOOTBALL: yield new FootballPlayer();
…
case null, default:
throw new IllegalArgumentException(
“Invalid player type: ” + playerType);
…
Or, like this:
case TENNIS: yield new TennisPlayer();
case FOOTBALL: yield new FootballPlayer();
…
case null:
case default:
throw new IllegalArgumentException(
“Invalid player type: ” + playerType);
…
Of course, null can be chained next to any other case not only the default case. Here, is chained next to the UNKNOWN case:
case TENNIS -> new TennisPlayer();
case FOOTBALL -> new FootballPlayer();
…
case null, UNKNOWN ->
throw new UnknownPlayerException(“Player type is unknown”);
default ->
throw new IllegalArgumentException(
“Invalid player type: ” + playerType);
…
Personally, I suggest you think twice before patching your switch expressions with case null, especially if you plan to do it only for silently sweeping these values. Overall, your code may become brittle and exposed to unexpected behaviors/results that ignore the presence of null values. In the bundled code, you can test the complete examples.