Sometimes when you are debugging, you have unreachable code fragment. Is there anyway to suppress the warning?
-
Probably not - unreachable code is usually a sign of a badly coded method.. could you post it up? Must be some way to refactor it. – Roy Truelove May 17 '11 at 01:36
-
14Sounds like he added an early return, or possibly an `if (false) ...`, for debugging. Nothing wrong with that. – Daniel Lubarov May 17 '11 at 01:39
-
why suppress the warning during debugging? the warning is there to remind you to remove the code after you finish debugging - IMO it's best *not* to suppress any debugging-related warnings. Suppression makes sense for *known and unneeded warnings* in *production code*. – Jan 04 '16 at 15:20
-
@vaxquis but some codes are not intended to reach production ever. Doesn't mean you'd write bad code but less warnings would be nice. – Mohammad Moghimi Jan 05 '16 at 22:26
-
@MohammadMoghimi I never said it's *bad* - but: if it's 'serious', in this case it should be fixed instead of using warning suppression. if it isn't 'serious' code, the warning shouldn't matter: either you write the code as "write once, execute many" (e.g. RegEx) - and then you just *don't go back to that code* (in which case the warning *doesn't hurt you* - leave it alone!) - or you write debug code - in which case use the warning to remind you of the debug code to be removed - or it's 'serious' (reusable, AKA *production* code), in which case just **don't** suppress it! – Jan 05 '16 at 23:33
-
1@vaxquis I cannot agree more. – Mohammad Moghimi Jan 07 '16 at 04:57
4 Answers
Java has (primitive) support for debugging like this in that simple if
on boolean constants will not generate such warnings (and, indeed when the evaluation is false the compiler will remove the entire conditioned block). So you can do:
if(false) {
// code you don't want to run
}
Likewise, if you are temporarily inserting an early termination for debugging, you might do it like so:
if(true) { return blah; }
or
if(true) { throw new RuntimeException("Blow Up!"); }
And note that the Java specification explicitly declares that constantly false conditional blocks are removed at compile time, and IIRC, constantly true ones have the condition removed. This includes such as:
public class Debug
{
static public final boolean ON=false;
}
...
if(Debug.ON) {
...
}

- 63,018
- 25
- 139
- 189
-
1javac doesn't generate warnings for `if (false)`, but the Eclipse compiler does. – Daniel Lubarov Oct 10 '12 at 20:14
-
@Daniel: That's unfortunate; it shouldn't for a plain `if(false)` or when the the only condition variable is `static final boolean` set to `false`. – Lawrence Dol Oct 11 '12 at 00:00
-
3I like the warning because it reminds me to go back and do something about the dead code, but IIRC it defaulted to error in an old version of Eclipse, so I would resort to stuff like `if (Math.abs(0) == 0)`. – Daniel Lubarov Oct 11 '12 at 19:00
-
+1 This does not cause any "Dead code" warnings in Java. The key is that your constant boolean flag must be the only expression in the `if`. If you use `if (Debug.ON)` this will work, but `if (Debug.ON && anotherExpression)` will not work (generate a warning). By the way, the "Dead code" warning is not equivalent to the "Unreachable code" _error_. – caw Nov 28 '13 at 19:36
-
@Daniel: Your example, `if (Math.abs(0) == 0)` is not the kind of constant expression I am talking about; what I am saying is only those which *are* or *are compiler-inlined to* `if(false)` or `if(true)`. When a constant `final` variable is used in code it's value and not it's reference are inlined by the compiler. You need to read the spec on the difference between a constant final and an inconstant final (or on assigned from a derived value). – Lawrence Dol Nov 29 '13 at 18:47
-
@SoftwareMonkey the JLS just says that `if (false)` "does not result in a compile-time error", not that it can't cause warnings. Compilers "may choose to omit the code for that statement from the generated class file", but there's no requirement, and the removal can be done after generating warnings anyway. The latest Eclipse compiler with default settings generate a warning for `if (false)`. IntelliJ also generates a "Constant 'if' statement" warning. – Daniel Lubarov Nov 29 '13 at 20:26
The only way to do this on any compiler is @SuppressWarnings("all")
.
If you're using Eclipse, try @SuppressWarnings("unused")
.

- 7,796
- 1
- 37
- 56
-
This is not the only way at all. See my answer (http://stackoverflow.com/a/6025389/8946). – Lawrence Dol Oct 09 '12 at 18:11
-
@SoftwareMonkey your approach still causes warnings in Eclipse and IntelliJ. This is the only solution that works across compilers and IDEs. – Daniel Lubarov Nov 29 '13 at 20:32
As Cletus tells us,
It depends on your IDE or compiler.
That said, at least for Eclipse, there is not a way to do this. With my Eclipse configuration, unreachable code causes a compile-time error, not just a warning. Also note this is different from "dead code," e.g.
if (false)
{
// dead code here
}
for which Eclipse (by default) emits a warning, not an error.
-
You can change code from "unreachable" to "dead" by using "if (true)" in front of the return or throw statement. – plugwash Jan 27 '20 at 21:02
According to the Java Language Specification:
It is a compile-time error if a statement cannot be executed because it is unreachable.
You can sometimes turn unreachable code into dead code (e.g., the body of if (false) {...}
). But it being an error is part of the language definition.

- 16,024
- 8
- 58
- 85

- 232,168
- 48
- 399
- 521