Community
Participate
Working Groups
Build Identifier: 20110916-0149 switch (1) { case 1: System.out.println(1); break; case 2: System.out.println(2); break; default: System.out.println(3); break; } All cases except "case 1" will clearly never be executed. I expected the superfluous case/default statements to be flagged by the compiler but they were not. Reproducible: Always
I am referring to the Dead Code compiler problem option.
Whats the use case for this? Why would one switch on a literal as shown?
Ayushman, I have no idea what the use case would be. However, I verified that javac also accepts this goofy code. I discovered it while testing switch semantics using 1.7 to see what syntax is allowed and disallowed.
(In reply to comment #3) > Ayushman, I have no idea what the use case would be. However, I verified that > javac also accepts this goofy code. I discovered it while testing switch > semantics using 1.7 to see what syntax is allowed and disallowed. Yes the code is legal. I'm sure no1 spent time in implementing the dead code analysis to such cases just because nobody uses a switch statement like that. So I guess we'll let this one be. Planning to close as WONTFIX.
True, but Eclipse does implement dead code checking for "if(false)" -- I don't think that's very common either. In any event, I wanted to raise this issue since what was expected didn't occur.
JLS3 section 14.21 spell out the conditions of unreachableness. For a switch statement it reads: A statement in a switch block is reachable iff its switch statement is reachable and at least one of the following is true: Ÿ It bears a case or default label. Ÿ There is a statement preceding it in the switch block and that preceding statement can complete normally. So there is no dead code here from the spec p.o.v. From the same section: Except for the special treatment of while, do, and for statements whose condition expression has the constant value true, the values of expressions are not taken into account in the flow analysis. For example, a Java compiler will accept the code: { int n = 5; while (n > 7) k = 2; } even though the value of n is known at compile time and in principle it can be known at compile time that the assignment to k can never be executed. A Java compiler must operate according to the rules laid out in this section. ----------------- This is not fixable in eclipse without going against Java language specification.
(In reply to comment #6) > JLS3 section 14.21 spell out the conditions of unreachableness. > For a switch statement it reads: > > A statement in a switch block is reachable iff its switch statement is > reachable > and at least one of the following is true: > Ÿ It bears a case or default label. > Ÿ There is a statement preceding it in the switch block and that preceding > statement can complete normally. > > So there is no dead code here from the spec p.o.v. Actually this is a part of reachability analysis, for which we have a different warning - "Unreachable code". So this analysis doesn't really apply to the "dead code" warnings - which are eclipse specific. javac doesnt elicit "dead code" warnings at all, so there's no question of complying with JLS or javac for the dead code diagnostic. Dead code warnings are generated by our own null analysis. Eg: Object p = null; if (p!= null) { // do something } the whole if block above is marked as dead code. Hence changing resolution to WONTFIX
