Using negative numbers to return error conditions

Question

In a method where any positive number returned would signify success, would it be good practice to use negative numbers to define error conditions? Could then use enums to make readable.

Answer 1

It's often language dependant. Quite common practice in languages such as C and C++, but where other mechanisms exist it's preferable to use them, for example exceptions. They allow decoupling - both conceptual and in code - of usage of the method result from dealing with errors.

int result = myFunction();
if (result < 0) dealWithError(result);
else proceedNormally();

is arguably less easy to reason about and code than a try-catch block (which can be placed anywhere in the calling hierarchy, without the explicit need to propagate error results - though some languages like Java will require/recommend a signature change. E.g.

myFunctionChecked() {
   try {
      myMethod();
   }
   catch (Exception e){
      dealWithExcpetion(e)
   }
}

and

myOtherFunctionChecked() {
   try {
      myOtherFunction();
   }
   catch (Exception e){
       dealWithExcpetion(e)
   }
}
myOtherFunction() {
   //... some stuff
   myFunction();
   //... some other stuff
}

can both be used without any change to how myFunction reports its errors if exceptions are used.

Final point for exceptions is that they allow you to be consistent about how you report errors throughout your code, not depending on the range of the function.

Answer 2

(...), would it be good practice to use negative numbers to define error conditions?

Providing error messages and valid return values using the same channel is rarely a good idea.

See how on a typical *nix standard input, output and error are separate - try to mirror that in your application. If your language of choice provides constructs dedicated to error handling (e.g. exceptions) - use them; treat returning error codes as a method of last resort if nothing else is available.

It is easier to think about your program's control flow if you can be sure that a channel always provides valid data without ambiguity (if your "valid data" can be either "return value" or "error message" you cannot be sure that the data returned by a function is always valid).

Answer 3

Overloading the meaning of any encoding is a dangerous thing.

Here a message code means both:

• success / failure
• Id's the specific message

Here is how that double meaning will evolve:

• Future programmers will curse the API when they realize that they must send a message in order to just say "success."
• Future future programmers will curse the design when they realize that "-999" was hijacked to mean "false with no message", but is within the domain of valid message IDs.
• Parsing "true" and "false" string literals. Or "success" and "failure". Most likely both.
• Actually storing space character(s) as the value in the database.
• There may be lists of "black listed" and "white listed" numbers, as above. Most likely simply in-line coded at various points.
• Everyone will wonder what idiot does not understand "null" or "true/false"
• There will be exceptional handling code everywhere.

Please pardon the harshness, a bit of PTSD going on here.

• There will come a time when this will adversely affect maintenance.
• Maintenance effort is O(n*2) because we have to deal with the database too.

Answer 4

I have in the past used a system where a return value of 0 meant success, any positive value meant success with some annotation that the caller could interpret in some way, and any negative value meant an error.

With this system it was generally possible to check for success or failure very easily. If a method returned more status it was easily possible to check that. And it was easily possible to check for exactly what error happened.