Not specifying a return in a function, good or bad?

Question

I have coded like this many times, and I've never encountered an issue, but the compiler always warns when it expects a return and there is none.

For instance, look at this:

-(NSString *)outputStringForInteger:(NSInteger)int
{
    if (int == 0)
    {
        return @"Number is Zero";
    }
    else
    {
        return @"Number is not Zero";
    }
    //no "failsafe" or other explicit return
}

If the function will never get to the last line, ever, is it important to still have a failsafe option, or do you guys just deal with compiler warnings?

Answer 1

Get a better compiler. The ones I use complain that you have code which will never execute if you put the "failsafe" return in there. That's a much better warning that the false one you're apparently seeing.

Answer 2

Not sure what language you're in so I'll use Java for my example.

String outputStringForInteger(int i) {
   String returnString = "Number is not Zero";

   if (i == 0)
      returnString = "Number is Zero";

   return returnString;
}

This will provide a "default" return value, as well as being more readable(IMO).

Answer 3

In C:

String outputStringForInteger(int i) {
   return (i == 0) ? "Number is Zero" : "Number is not Zero";
}

If you insist that the ternary operator is an invention of the Devil, as some do:

String outputStringForInteger(int i) {
   String returnString;

   if (i == 0) {
      returnString = "Number is Zero";
   } else {
      returnString = "Number is not Zero";
   }
   return returnString;
}

Answer 4

I prefer not to have multiple returns in a function.

Answer 5

In D, except in a few trivial cases where the compiler can statically prove that the end of the function is unreachable without a return statement being executed or an exception being thrown, you must put either a return statement, a throw statement or an assert(0) at the end of the function. In other languages I think this is usually good practice, though not necessarily in cases like your example, where a reader could trivially and statically tell that the end of the function is unreachable and a decent compiler should be able to prove this.

You shouldn't have a default return value that you believe is unreachable. If it ever gets used your code is by definition in a state that you never intended for it to be in. An assert(0) conveys your intentions both to the reader and the compiler much better.

Answer 6

As long as you have covered all the possible code paths, you're fine.

If your compiler is complaining, there's two possibilities:
1) You think you covered everything and didn't.
2) Your compiler is brain dead.

That said, there's most likely a way that you can restructure the code to placate the compiler and still cover the code paths. (e.g., drop the else in your example)

Answer 7

How about this (Java - I don't know the OP's language)?

String outputStringForInteger(int i)
{

   if (i == 0)
      return "Number is Zero";

   return "Number is not Zero";
}