Why does this code have a missing return statement error?

Question

If I change the else if portion of this code to an else statement it runs without any problems so I get how to make it run. What I\'m a little confused about is why I get a

Answer 1

You should have a return in all your branches.

public boolean posNeg(int a, int b, boolean negative) {
  if (!negative) {
    return (a < 0 && b > 0) || (a > 0 && b < 0);
  }
  else if (negative) {
    return (a < 0 && b < 0);
  }
}

The method above logically has a return in all branches, but technically it does not. We like the Java compiler to be fast, therefore it is undesirable to have a Java compiler analyzing semantically the code.

public boolean posNeg(int a, int b, boolean negative) {
  if (!negative) {
    return (a < 0 && b > 0) || (a > 0 && b < 0);
  }
  else {
    return (a < 0 && b < 0);
  }
}

The method above has a return in all the branches.

public boolean posNeg(int a, int b, boolean negative) {
  if (!negative) {
    return (a < 0 && b > 0) || (a > 0 && b < 0);
  }
  return (a < 0 && b < 0);
}

However, as you can see above, you do not even need the else, because if the code ever reaches the second return, then negative is certainly false, as if it was true, the first return would end the algorithm.

public boolean posNeg(int a, int b, boolean negative) {
  return ((negative) && (a < 0 && b < 0)) || ((!negative)  && (a < 0 && b > 0) || (a > 0 && b < 0));
}

The method above is a one-liner.

public boolean posNeg(int a, int b, boolean negative) {
  return ((negative) && (a < 0 && b < 0)) || ((!negative)  && ((a < 0) == (b > 0)));
}

The method above uses the fact that in the second case the positivity of a is equal with the negativity of b.

Answer 2

When the compiler sees else if without an else or a trailing return statement, it cannot be certain that all control paths will lead to a valid return statement.

The compiler can be smart at times, but it can't be smart in this situation (nor should it be).

This behavior is helpful in your example: there's absolutely no reason for you to use an else if in this situation. A simple else is easier to read, more concise, and less error prone.

An else is very expressive in this case. It means "the opposite of the if clause" which will still be the case if the code changes in the future.

Your current code would be more likely to contain and/or introduce a bug if the compiler allowed it.

Here's how I would rewrite the method body:

if (negative) {
    return (a < 0 && b < 0);
}
else {
    return (a < 0 && b > 0) || (a > 0 && b < 0);
}

In general you should prefer if (negative) over if (!negative) unless there's a compelling reason (ie readability) to do otherwise.

Also, a lot of people (including myself) try to put the most simple clause first in an if/else statement. Making your code easy to read is a good thing.

Check out StephenC's answer for a technical explanation and more background about why the compiler behaves this way.

Answer 3

You do not need "if (negative) {}" in the "else" brace

Answer 4

if => else if => where is the else condition?

For a return statement, all branches (conditions) must be handled.

You could do:

if (!negative)
  return (a < 0 && b > 0) || (a > 0 && b < 0);
return (a < 0 && b < 0);

or:

if (!negative)
  return (a < 0 && b > 0) || (a > 0 && b < 0)
else
  return (a < 0 && b < 0);

or (my preferred way):

return negative ? (a < 0 && b < 0) : (a < 0 && b > 0 || a > 0 && b < 0)

However, I'd recommend to avoid the negative condition, it's harder for the human brain in complex scenario. Even some Java IDEs like IntelliJ helps to find those patterns to fix them.
You'd end up with:

if (negative)
      return (a < 0 && b < 0);
else
      return (a < 0 && b > 0) || (a > 0 && b < 0);

Answer 5

I think you already know that the second if is redundant.

if (negative) is interpreted context-free, which means that the compiler ignores that if(!negative) has already been handled.

Answer 6

Other questions have explained what the error message means from an intuitive perspective. However the "The compiler is smart, but not perfect!" comment is missing the point.

In fact, the Java compiler is calling your example an error because the Java Language Specification requires it to call it an error. The Java compiler is not permitted to be "smart" about this.

---

Here is what the JLS (for Java 7¹) actually says, and how it applies to a simplified version of the incorrect example, and then a corrected version.

"If a method is declared to have a return type, then a compile-time error occurs if the body of the method can complete normally (JLS 14.1). In other words, a method with a return type must return only by using a return statement that provides a value return; it is not allowed to "drop off the end of its body". " - JLS 8.4.7

(Read JLS 14.1 for the definition of "normal completion" ...)

And the rules for deciding whether a "normal" completion is possible are the reachability rules in JLS 14.21. And they say:

1. "An if-then statement can complete normally iff it is reachable."
2. "An if-then-else statement can complete normally iff the then-statement can complete normally or the else-statement can complete normally."
3. "A break, continue, return, or throw statement cannot complete normally."

(Where 'iff' means "if and only if" ...)

Consider a simplified version of the example:

   public int test(boolean a) {
      if (a) {
        return 1;
      }
      else if (!a) {
        return 0;
      }
   }

In this example, the else-statement is an if-then which can complete normally by rule #1. Therefore, by rule #2, the if-then-else statement can also complete normally. But that is a compilation error, because JLS 8.4.7 says that a method with a return type cannot complete normally.

But if you change the example to this ...

  public int test(boolean a) {
      if (a) {
        return 1;
      }
      else {
        return 0;
      }
  }

Now by rule #3, both the if-statement and the else-statement cannot complete normally. So by rule #2, the entire if-then-else cannot complete normally. That is what it required by JLS 8.4.7 ... therefore no compilation error.

^{1 - The Java 8 JLS will say essentially the same thing, though the section numbers may be different ...}