1

I already searched in stackoverflow for reasons concerning the question, why switch does not break after having found a matching case.

For example, I have written some code which simulates a dice. For every throw, I count up for statistical reasons (one, ... = int).

switch (actualThrow) {
case (1): one++; 
case (2): two++; 
case (3): three++; 
case (4): four++;
case (5): five++; 
case (6): six++; 
}

I DO know, that case(3)-case(6) will be checked, if my throw was a 3 (Why do we need break after case statements?) and it will be prevented by inserting break;, but I want to understand, why obviously the following cases seem to be checked, but execute, although the condition is not fulfilled.

Community
  • 1
  • 1
Gary Klasen
  • 1,001
  • 1
  • 12
  • 30
  • The various cases in a switch *fall through* until the switch ends or they reach a break. The condition check only determines the *starting* case. – thegrinner Jun 07 '13 at 20:33
  • So you understand that you need `break`s but want to know why the subsequent cases are executed? I'm sorry, but I don't understand the question. – jerry Jun 07 '13 at 20:34
  • i understand, that subsequents are executed, so i need `break`s. i do not understand, WHY the checking fails. – Gary Klasen Jun 07 '13 at 20:38
  • Because there is no checking after the jump to the matching case. The cases are merely entry points. – Andy Thomas Jun 07 '13 at 20:40
  • Voting to reopen. None of the answers in the duplicate cite the JLS that explains why this is the case. – Brian Roach Jun 07 '13 at 20:40
  • It's not checking anymore and it's not failing. It looks for the first label that matches your `actualThrow` and continues until it finds the end of statement (for the switch statement) or a `break;`. That's the behavior given to a switch statement. – BLaZuRE Jun 07 '13 at 20:40
  • 1
    Because (1): there can be a "default" that needs to be executed; (2): there can be more than one case per block (ie, case 1: case 2: case 3: lowroll++;); and, (default): it is what it is. – michael Jun 07 '13 at 20:42
  • @michael_n I disagree with part (1) of your comment. I don't think the fallthrough is simply because there *might* be a `default:` label. Also, a `default:` statement can be placed at the top, it's simply convention we put it at the bottom. – BLaZuRE Jun 07 '13 at 20:49
  • @BLaZuRE I agree with you; I frankly don't completely understand what the questioner is really looking for, other than some way to better understand why it is the way it is; ie, more practical examples rather than a spec clarification. – michael Jun 07 '13 at 20:54
  • @BLaZuRE based on the accepted answer, sounds like my case #2 is really what was needed to clarify the situation. – michael Jun 07 '13 at 20:59

2 Answers2

5

Imagine this scenario:

switch(trafficLight.state) {
    case GREEN:
        car.drive();
        break;
    case YELLOW:
        car.drive();
        break;
    case RED:
        car.stop();
        break;
}

Seems kinda wasteful since GREEN and YELLOW both do the same thing. Java lets us consolidate so that multiple conditions take the same action:

switch(trafficLight.state) {
    case GREEN:
    case YELLOW:
        // Now both GREEN and YELLOW will use this code
        car.drive();
        break;
    case RED:
        car.stop();
        break;
}

Less code, same effect. That's all. That's the simple case mind you, there are other ways to use this that are less obvious and more prone to abuse.

Chris Eberle
  • 47,994
  • 12
  • 82
  • 119
0

When parsing through a switch-case statement, each case is simply a label. If anything matches a case then it will just go through until it either finds a break or the end of the statement (a }).

It is similar to the Java opcode (assembly code essentially). You use labels to jump to. Besides that, they don't really serve a purpose in the code.

BLaZuRE
  • 2,356
  • 2
  • 26
  • 43