Java: How to @SuppressWarnings unreachable code?

Question

Sometimes when you are debugging, you have unreachable code fragment. Is there anyway to suppress the warning?

Kola

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. – Cacomistle

Sounds like he added an early return, or possibly an if (false) ..., for debugging. Nothing wrong with that. – Lemkul

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. – Arndt

@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. – Kola

@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! – Arndt

@vaxquis I cannot agree more. – Kola

Answer 1

The only way to do this on any compiler is @SuppressWarnings("all").

If you're using Eclipse, try @SuppressWarnings("unused").

Lemkul

This is not the only way at all. See my answer (https://mcmap.net/q/969403/-java-how-to-suppresswarnings-unreachable-code). – Thorpe

@SoftwareMonkey your approach still causes warnings in Eclipse and IntelliJ. This is the only solution that works across compilers and IDEs. – Lemkul

Answer 2

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) {
    ...
    }

Thorpe

javac doesn't generate warnings for if (false), but the Eclipse compiler does. – Lemkul

@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. – Thorpe

I 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). – Lemkul

+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. – Teri

@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). – Thorpe

@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. – Lemkul

Answer 3

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.

Enemy

You can change code from "unreachable" to "dead" by using "if (true)" in front of the return or throw statement. – Pettifogger

Answer 4

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.

Kindig