CODEWITHSUNDEEP
c#compiler-errors
Ricibob
Ricibob

Reputation: 7705

.NET compiler and "Not all code paths return a value"

Why in code like below is the .NET compiler not able to establish that all code paths do return a value?

bool Test(bool param) {
    bool test = true;
    if (param)
        test = false;
    else
        test = false;
    if (!test)
        return false;
}

error CS0161: Not all code paths return a value!

The code can be refactored - but the compiler is not suggesting that. Yet all return paths are covered - so why does the compiler complain that they are not?

Edit: I guess the conclusion here is that: 

(error CS0161) + (all code paths obviously return a value) => refactor code.

Once you get the habit of that translation I guess everything is ok.

Upvotes: 2

Views: 3479

Answers (5)

ASHWANI KUMAR SINGH BISEN
ASHWANI KUMAR SINGH BISEN

Reputation: 130

Instead of going in much detail let me answer you question straight.

  1. Return type of function is specified as Bool hence the function must return True or false
  2. Param has been defined as input parameter hence its value can not be determined at compile time
  3. value of test variable is dependent on param and as per step-2, param value can not be determined at compile time and hence value of test can not be determined at compile time
  4. As value of test is not known as compile time(as per step-3) hence it start looking for a else / default root for if (!test) and hence it throws error.

thanks

Upvotes: 0

Xaqron
Xaqron

Reputation: 30837

Let's backward analyze the code:

Problem: Code doesn't return any value.

Question: Where in code a value is returned?

Answer: Just at the last line.

Conclusion: So that line of code (last line) should always return a value.

Question: Does last line always return a value?

Answer: No, it only returns value if test is false while it has been set to true at the first line.

Conclusion: As compiler says, this function never returns a value while it is supposed to return bool.

Upvotes: 1

Michael Burr
Michael Burr

Reputation: 340198

From the C# Language Specification 4.0 included with Visual Studio 2010.

10.6.10 "Method body":

When the return type of a method is not void, each return statement in that method’s body must specify an expression that is implicitly convertible to the return type. The endpoint of the method body of a value-returning method must not be reachable. In other words, in a value-returning method, control is not permitted to flow off the end of the method body.

The definition of reachability is here (emphasis added):

8.1 "End points and reachability":

If a statement can possibly be reached by execution, the statement is said to be reachable. Conversely, if there is no possibility that a statement will be executed, the statement is said to be unreachable.

...

To determine whether a particular statement or end point is reachable, the compiler performs flow analysis according to the reachability rules defined for each statement. The flow analysis takes into account the values of constant expressions (§7.19) that control the behavior of statements, but the possible values of non-constant expressions are not considered.

Since !test isn't a constant expression (even though it will always evaluate to true), the compiler is obliged to not consider it in the flow analysis. One reason (maybe the only reason) for this restriction is that performing this kind of flow analysis is impossible in the general case.

To get rid of the error, you'll need to have another return statement, either in an else clause or unconditionally at the end of the method.

Upvotes: 11

dtb
dtb

Reputation: 217263

From Eric Lippert's blog:

The reachability analyzer is not very smart. It does not realize that there are only two possible control flows and that we've covered all of them with returns.

(The blog post is on switch statements, but I guess the reachability analyzer isn't much smarter for if statements.)

Upvotes: 10

Jonathan Wood
Jonathan Wood

Reputation: 67193

This just represents the limitations in how smart the compiler is with regard to what gets initialized and which lines will be executed.

I run into this from time to time. But it's very seldom that it's a problem. I would normally just restructure the code a little.

Upvotes: 3

Related Questions