A switch block comprises several case labels and an optional but highly recommended default label. Statements that follow each case label must end with a break statement, which is responsible for transferring the control to the end of the switch block. When omitted, the statements in the subsequent case label are executed. Because the break statement is optional, omitting it produces no compiler warnings. When this behavior is unintentional, it can cause unexpected control flow.
Noncompliant Code Example
In this noncompliant code example, the case where the card is 11 lacks a break statement. As a result, execution continues with the statements for card = 12.
int card = 11;
switch (card) {
/* ... */
case 11:
System.out.println("Jack");
case 12:
System.out.println("Queen");
break;
case 13:
System.out.println("King");
break;
default:
System.out.println("Invalid Card");
break;
}
Compliant Solution
This compliant solution terminates each case (including the default case) with a break statement:
int card = 11;
switch (card) {
/* ... */
case 11:
System.out.println("Jack");
break;
case 12:
System.out.println("Queen");
break;
case 13:
System.out.println("King");
break;
default:
System.out.println("Invalid Card");
break;
}
Applicability
Failure to include break statements can cause unexpected control flow.
The break statement at the end of the final case in a switch statement may be omitted. By convention, this is the default label. The break statement serves to transfer control to the end of the switch block. Fall-through behavior also causes control to arrive at the end of the switch block. Consequently, control transfers to the statements following the switch block without regard to the presence or absence of the break statement. Nevertheless, the final case in a switch statement should end with a break statement in accordance with good programming style [Vermeulen 2000].
Exceptionally, when multiple cases require execution of identical code, break statements may be omitted from all cases except the last one. Similarly, when processing for one case is a proper prefix of processing for one or more other cases, the break statement may be omitted from the prefix case. This should be clearly indicated with a comment. For example:
int card = 11;
int value;
// Cases 11,12,13 fall through to the same case
switch (card) {
// Processing for this case requires a prefix
// of the actions for the following three
case 10:
do_something(card);
// Intentional fall-through
// These three cases are treated identically
case 11: // Break not required
case 12: // Break not required
case 13:
value = 10;
break; // Break required
default:
// Handle error condition
}
Also, when a case ends with a return or throw statement, the break statement may be omitted.
Automated Detection
| Tool | Version | Checker | Description |
|---|---|---|---|
| Parasoft Jtest | 2024.2 | CERT.MSC52.SBC | Do not use a "switch" statement with a bad "case" |
| SonarQube | 9.9 | S128 |



7 Comments
James Ahlborn
I fail to see how this is a recommendation, other than a recommendation to have correct logic in your code. missing break statements aren't bad style, they are incorrect code logic. as it stands, this rule is currently equivalent to the recommendation "have correct logic in your if blocks or else your code won't do what you expect".
that said, i feel that there is a useful recommendation around switch blocks which doesn't seem to be addressed anywhere. that is the recommendation that if your switch block intends to cover all cases, then you should have a default case which throws an exception. this protects code from subtle bugs in the future where a new value was added and no corresponding case statement was added. without the default case which throws an exception, the code will continue past the switch block, doing who knows what after that.
James Ahlborn
I guess the second part of my comment about always having a default case is covered briefly in MSC60-JG.
Dean Sutherland
I agree that this one is weak. For the moment, I've added text permitting intended fall-through when processing for one case is a proper prefix of that for one or more other cases – with a suitable comment indicating that fall-though is intended. We need comment from the other authors one whether to keep this rule.
Dhruv Mohindra
I am not a big fan of this one because it is a very basic programming guideline.
Fred Long
It's a fairly common mistake by novice programmers, so I think that we should keep this guideline.
Ioannis Kostaras
A good place here to mention the new switch statement syntax introduced in Java 12.
David Svoboda
Agreed, this recommendation will be a good place to showcase the new switch syntax proposed in JEP 325, and updated in JEP 354.
However, because this syntax is a "preview feature", and hence not guaranteed to exist in future versions of Java, mentioning it in this guideline now is premature.