CODEWITHSUNDEEP
javacompiler-warningscompile-time-constant
dCSeven
dCSeven

Reputation: 915

Correctly formulate conditions for constants?

I have a constant in my project, that represents some timespan. When it is below 0, I want to disable the timespan related checks.

Normally one would check

if(CONSTANT > 0) foo();
else bar();

but this causes the warning "Condition is always 'false'" or "Condition is always 'true'" depending on the value of the constant.

Is there a way to circumvent this warning, to prevent another dev to just that lines?

EDIT: I was a bit too generic with my question. Sorry about that.

I'm having a Timer, that after some time TIME_FOR_AUTH (the constant) has passed, clears my model. This is a security measure, that makes problems while testing. Therefore I added a check, if(TIME_FOR_AUTH > 0) ... to my code.

Now I get the described warning. Since IntelliJ always asks me to delete this construct (and I'm not alone in this project), I wanted to know if there is a common practice doing that in Java / some possibility to suppress the warning.

Upvotes: 0

Views: 348

Answers (2)

GhostCat
GhostCat

Reputation: 140613

Here:

if(CONSTANT > 0) foo();

You say it yourself. It is a constant. Thus, right from the start, it is either bigger or smaller than 0. Thus the compiler gleefully turns the above into:

if(...x... > 0) foo();

where x would be the actual value that you assigned to CONSTANT. So right there, at compile time, this turns into

if (true)

or maybe if (false).

Long story short: rethink what you are doing. Probably you shouldn't comparing your CONSTANT, but something like:

LocalDateTime endTime = LocalDateTime.now().plusHours(1);

and then, later:

if (LocalDateTime.now().isAfter(endTime)) {

or something like that.

In other words: comparing a constant value to identify a certain condition simply doesn't much sense. Instead you can use the constant to compute some "end time", and then, over time check the current time against that "end time". Especially when using a class like LocalDateTime it is extremely easy to compute a later timestamp, as shown above.

Edit, given the edit to the question: I still suggest to NOT have such a construct in production code. Instead, I would look into means so that the test setup can configure the production in a way that allows it to effectively disable such a timeout mechanism. For example by injecting a timeout that is guaranteed to not be hit during reasonable test execution time!

Upvotes: 4

Dmitriy Popov
Dmitriy Popov

Reputation: 2360

At first, this is just a warning.

At second, you can suppress the warning using @SuppressWarnings annotation. For "is always true/false" warning, it would be @SuppressWarnings("ConstantConditions")

Code example:

package stackoverflow;

public class SuppressWarningsExample {

    @SuppressWarnings("ConstantConditions")
    public static void main(String[] args) {
        final int value = 100;

        if (value > 0)
            System.out.println("Yes");
        else
            System.out.println("No");
    }
}

For IntelliJ IDEA, you can also suppress warning per-expression with an inline // noinspection <InspectionName> comment:

// noinspection ConstantConditions
if (value > 0)
    System.out.println("Yes");
else
    System.out.println("No");

Upvotes: 4

Related Questions