Techniques to deal with "not all code paths return a value" when your algorithm already takes care of it [closed]

Question

In C#, sometimes there are code paths that don't return a value, and it is nice that the compiler errors out, and allows you to fix them. However there are times where there STRUCTURALLY is a place where it doesn't, but the ALOGIRTHM would prevent that structure from happening.

Here is a simple contrived example.

public static int test1(bool a)
    {
        if (a) return 1;
        if (!a) return 2;
    }

Of course people will tell me , that my "algorithm" is stupid and my second test is redundant and I should just do.

public static int test1(bool a)
    {
        if (a) return 1;
        else return 2;
    }

or even

public static int test1(bool a)
    {
        if (a) return 1;
        return 2;
    }

I purposely choose this simple "Redundant" example, rather than my real world algorithms, as I want to focus on this issue specifically, not about 10 different ways I could have written the algorithm :)

So what are the possible ways to deal with this, and what are the pro's and con's of each.

1) is what we just covered, and that's refactor the algorithm. Sometimes this may not be possible, or the end result may not be as per formant, easy to read/understand or maintain.

other is just to return something that would never happen, such as null.. but in this case i'm dealing with an integer and i'd have to put 0, which feels ever dirtier

public static int test1(bool a)
    {
        if (a) return 1;
        if (!a) return 2;
        //this code never happens, but i need to keep the compiler happy
        return 0;
    }

or use exceptions

public static int test1(bool a)
    {
        if (a) return 1;
        if (!a) return 2;
        throw new Exception("this code never happens, but i need to keep the compiler happy");
    }

however every time I've dealt with this , no matter what technique I take i'm not happy with the result and feel a little dirty.

Are there alternatives?

Answer 1

Generally you throw Exceptions when there is an exceptional case... a bool not being true or false would be rather exceptional! I would throw an exception to keep the compiler happy, but also because you don't know how the method could change in the future.

I wouldn't consider an if ... else as dirty when dealing with a bool for exactly the reason that you use bools, they only have two values, when there are more possibilities (i.e. a string) then you can use more complex test.

Answer 2

When you have a compile error that all your code paths do not return a value, there is no flag to set or "trick," you have to either return a default value or throw an exception. I'm a firm believer in throwing an InvalidOperationException("Unexpected code reached, this method has been modified incorrectly").

Why it's not dirty: if someone else comes along and makes a change that causes your exception to be thrown, they'll know they did something that the author of the exception viewed as fundamentally wrong. Returning a default value could quietly break the consumers of the method, so it's good practice to use an exception as a safety net.