Why doesn't "switch" statement have "break" as default?

[MaXiaochi]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.
In fact,I appreciate the counterpart "DO CASE ... ENDCASE" in
VFP,which takes not only equality but also other boolean expressions at
every case.If the expression is true, the coomands just after this case
excutes,ignoring other case,no matter they are true or not.I think it
much more convenient.
For example,to classify people by age,you code like this:
DO CASE
CASE age<3
kind=baby
CASE age<14
kind=child
CASE age<18
kind=adolescent
OTHERWISE
kind=adult
As to Java,the best way to achieve it is to use "if-else",only if we
divide people by 5,10,15,20, the "switch" is useful.

 

[Betty]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.
In fact,I appreciate the counterpart "DO CASE ... ENDCASE" in
VFP,which takes not only equality but also other boolean expressions at
every case.If the expression is true, the coomands just after this case
excutes,ignoring other case,no matter they are true or not.I think it
much more convenient.
For example,to classify people by age,you code like this:
DO CASE
CASE age<3
kind=baby
CASE age<14
kind=child
CASE age<18
kind=adolescent
OTHERWISE
kind=adult
As to Java,the best way to achieve it is to use "if-else",only if we
divide people by 5,10,15,20, the "switch" is useful.

First of all, the java developers asked me if I wanted the break and
I said that I wanted it. Next, your example has no ENDCASE, so there.....

 

[Steven]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.
In fact,I appreciate the counterpart "DO CASE ... ENDCASE" in
VFP,which takes not only equality but also other boolean expressions at
every case.If the expression is true, the coomands just after this case
excutes,ignoring other case,no matter they are true or not.I think it
much more convenient.
For example,to classify people by age,you code like this:
DO CASE
CASE age<3
kind=baby
CASE age<14
kind=child
CASE age<18
kind=adolescent
OTHERWISE
kind=adult
As to Java,the best way to achieve it is to use "if-else",only if we
divide people by 5,10,15,20, the "switch" is useful.

I cannot think of a way of coding this without using a nested if
statement, but if it is that important to you you could make your code
look like this:

package test;

public class CaseEnumTest {

/**
* @param args
*/
public static void main(String[] args) {
test(1);
test(5);
test(15);
test(25);
test(85);
test(200);
}

public static void test(int age)
{
switch(CaseEnum.isAge(age))
{
case BABY:
System.out.println("baby");
break;
case YOUTH:
System.out.println("youth");
break;
case TEEN:
System.out.println("teen");
break;
case ADULT:
System.out.println("adult");
break;
case SENIOR:
System.out.println("senior");
break;
default:
System.out.println("ok really old");

}
}

}

package test;

public enum CaseEnum {
NONE,
BABY,
YOUTH,
TEEN,
ADULT,
SENIOR
;

public static CaseEnum isAge(int age)
{
if(age <3) { return BABY; }
else if(age <13) { return YOUTH; }
else if(age <20) { return TEEN; }
else if(age <65) { return ADULT; }
else if(age <100) {return SENIOR; }
return NONE;
}
}

--Steve

 

[Mike Schilling]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.

C and C++ compatibility.

 

[Boudewijn Dijkstra]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.

This is why:

switch (type)
{
case COMMAND_RC5:
case COMMAND_RC5_STRING:
case COMMAND_RC6_MODE_0:
buf = new byte[4];
buf[0] = info;
contentIndex = 1;
break;
case COMMAND_RC5_EXTENDED:
case COMMAND_CDI:
case COMMAND_RC6_MODE_2A:
buf = new byte[5];
buf[0] = info;
contentIndex = 1;
break;
case COMMAND_RC6_MODE_1A:
case COMMAND_RC6_MODE_5:
case COMMAND_RC6_MODE_6:
buf = new byte[3 + content.length];
buf[0] = info;
buf[1] = (byte) (1 + content.length);
contentIndex = 1;
break;
case COMMAND_RC6_MODE_1B:
buf = new byte[3 + content.length];
buf[0] = info;
buf[1] = (byte) (content.length >> 8);
buf[2] = (byte) content.length;
contentIndex = 3;
break;
default:
return null;
}

 

[Matthias Buelow]

C and C++ compatibility.

And simply because you might want to match the object against more
than one keys, for example:

switch (n) {
case 2: case 3: case 5: case 7: case 11:
return prime;
case 1: case 4: case 6: case 8: case 9: case 10:
return nonprime;
}

Of course you could also use `if' statements with or-connected
predicates, or make a function/method with the desired result
expression and put it into each matching `case' clause (to avoid
duplicating code), or even simply textually duplicate the code (not
recommended), etc. It's just syntactical sugar. Unfortunately,
the unwanted side effect is that fall-through can happen, like in
C. Other languages like for example Lisp or Scheme have more
flexible constructs that prevent such errors and give the programmer
more choice. Unfortunately Java has decided to stick with the C
`switch' and also doesn't provide any way of creating new syntax.

mkb.

 

[Hal Rosser]

Know what you mean. I learned VB first, too.
We just gotta bite the bullet, and remember to throw those break stmts in
there

 

[Betty]

Know what you mean. I learned VB first, too.
We just gotta bite the bullet, and remember to throw those break stmts in
there

If the 'break' is mandatory, how do you have the same code for
more than one switch value? And I don't mean in the 'default'
statement, because that trick can only be used once. There is no
goto remember.

 

[Oscar kind]

If the 'break' is mandatory, how do you have the same code for
more than one switch value? And I don't mean in the 'default'
statement, because that trick can only be used once. There is no
goto remember.

See the answers of Matthias and/or Boudewijn for that.

 

[Ben Caradoc-Davies]

C and C++ compatibility.

Which brings us to "Duff's device":

http://www.jargon.net/jargonfile/d/Duffsdevice.html
http://www.lysator.liu.se/c/duffs-device.html

"Many people (even bwk?) have said that the worst feature of C is that
switches don't break automatically before each case label. This code
forms some sort of argument in that debate, but I'm not sure whether
it's for or against."

I have not dared to see if Duff's Device works in Java. :->

 

[Tor Iver Wilhelmsen]

"Many people (even bwk?) have said that the worst feature of C is that
switches don't break automatically before each case label.

Should be continued: "Most of these come from a Pascal/Modula background."



C# "fixes" this by making it an error not to have a break or goto
<other label> at the end of each labeled section.

 

[John C. Bollinger]

Which brings us to "Duff's device":

http://www.jargon.net/jargonfile/d/Duffsdevice.html
http://www.lysator.liu.se/c/duffs-device.html

"Many people (even bwk?) have said that the worst feature of C is that
switches don't break automatically before each case label. This code
forms some sort of argument in that debate, but I'm not sure whether
it's for or against."

I have not dared to see if Duff's Device works in Java. :->

It does not. The Java version of the switch statement is more
structured than the C version: if the innermost block containing a case
statement is not the one introduced by a switch statement then the
compiler rejects the code. In particular:


public class Duff {
int i;
int[] j;

public void duff(int count) {
int n = (count + 7) / 8; /* count > 0 assumed */
int ctr = 0;
switch (count % 8)
{
case 0: do { i += j[ctr++];
case 7: i += j[ctr++];
case 6: i += j[ctr++];
case 5: i += j[ctr++];
case 4: i += j[ctr++];
case 3: i += j[ctr++];
case 2: i += j[ctr++];
case 1: i += j[ctr++];
} while (--n > 0);
}
}
}


D:\temp\testdir>javac Duff.java
Duff.java:12: orphaned case
case 7: i += j[ctr++];
^
Duff.java:13: orphaned case
case 6: i += j[ctr++];
^
Duff.java:14: orphaned case
case 5: i += j[ctr++];
^
Duff.java:15: orphaned case
case 4: i += j[ctr++];
^
Duff.java:16: orphaned case
case 3: i += j[ctr++];
^
Duff.java:17: orphaned case
case 2: i += j[ctr++];
^
Duff.java:18: orphaned case
case 1: i += j[ctr++];
^
7 errors

(That version of the Duff device adapted from the C code in the Jargon
file.)

 

[Thomas Schodt]

I have not dared to see if Duff's Device works in Java. :->

It does not.

<http://www.preemptive.com/documentation/NewObfuscation.html>

 

[Ross Bamford]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.

This is why:

switch (type)
{
case COMMAND_RC5:
case COMMAND_RC5_STRING:
case COMMAND_RC6_MODE_0:
buf = new byte[4];
buf[0] = info;
contentIndex = 1;
break;
case COMMAND_RC5_EXTENDED:
case COMMAND_CDI:
case COMMAND_RC6_MODE_2A:
buf = new byte[5];
buf[0] = info;
contentIndex = 1;
break;
case COMMAND_RC6_MODE_1A:
case COMMAND_RC6_MODE_5:
case COMMAND_RC6_MODE_6:
buf = new byte[3 + content.length];
buf[0] = info;
buf[1] = (byte) (1 + content.length);
contentIndex = 1;
break;
case COMMAND_RC6_MODE_1B:
buf = new byte[3 + content.length];
buf[0] = info;
buf[1] = (byte) (content.length >> 8);
buf[2] = (byte) content.length;
contentIndex = 3;
break;
default:
return null;
}

Couldn't have put it better myself.

 

[Hal Rosser]

AH - "break" ain't mandatory for every case in a switch
but if you leave it off
you oughta have a reason you leave it off
else
live with fall-thru

 

[Mike Schilling]

And simply because you might want to match the object against more
than one keys, for example:

switch (n) {
case 2: case 3: case 5: case 7: case 11:
return prime;
case 1: case 4: case 6: case 8: case 9: case 10:
return nonprime;
}

That's a slightly different issue; a language could certainly define that a
block can have multiple labels but there is no fall-through between blocks.

 

[Thomas G. Marshall]

Ben Caradoc-Davies coughed up:

Which brings us to "Duff's device":

http://www.jargon.net/jargonfile/d/Duffsdevice.html
http://www.lysator.liu.se/c/duffs-device.html

"Many people (even bwk?) have said that the worst feature of C is that
switches don't break automatically before each case label.

Far more than silly fall-throughs, which don't bug me that much, I
personally hate (without offering an alternative, so don't even ask) the
following:

long *a = 0; // assign 0 to the ptr

*a = 0; // assign 0 to the contents of the ptr

It is something that we all (probably) take as easy, but think in terms of a
newbie, and it is horribly counter-intuitive.

I also absolutely LOATH this:

long* a, b; // long pointer followed by a long

This code
forms some sort of argument in that debate, but I'm not sure whether
it's for or against."

I have not dared to see if Duff's Device works in Java. :->

--
Unix users who vehemently argue that the "ln" command has its arguments
reversed do not understand much about the design of the utilities. "ln
arg1 arg2" sets the arguments in the same order as "mv arg1 arg2".
Existing file argument to non-existing argument. And in fact, mv
itself is implemented as a link followed by an unlink.

 

[Grant Wagner]

AH - "break" ain't mandatory for every case in a switch
but if you leave it off
you oughta have a reason you leave it off
else
live with fall-thru

If I intentionally allow fall-through, I usually document it so another
developer (or myself 6 months later) doesn't look at the code and assume
it's a mistake:

switch (whatever)
{
case 0:
// don't break; allow fall-through
case 1:
break;
}

 

[Tim Tyler]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again, and the worse is that sometimes someone forget to do that.
So why don't the designers make it a default state?

That's easy:

Java 5? Backwards compatibility with Java 1.0;
Java 1.0? Backwards compatibility C;
C? The designers didn't know any better.

 

[Tim Tyler]

[Duff's device]

http://www.lysator.liu.se/c/duffs-device.html

ISTM that this bit:

``Actually, I have another revolting way to use switches to implement
interrupt driven state machines but it's too horrid to go into.

....is reminiscent of Fermat's Last Theorem ;-)