views:

185

answers:

5

I have gone through this and this,

but the question I am asking here is that why is 0 considered a Success?

We always associate 0 with false, don't we?

+18  A: 

Because there are more fail cases than success cases.

Usually, there is only one reason we succeed (because we're successful :)), but there are a whole lot of reasons why we could fail. So 0 means success, and everything else means failure, and the value could be used to report the reason.

For functions in your code, this is different, because you are the one specifying the interface, and thus can just use a bool if it suffices. For main, there is one fixed interface for returns, and there may be programs that just report succeed/fail, but others that need more fine error reporting. To satisfy them all, we will have multiple error cases.

Johannes Schaub - litb
+1 Indeed, when everything is OK the details are not interesting. But when we get an error, you want to know why.
Kirill V. Lyadvinsky
This doesn't answer why the same logic doesn't apply to the C/C++/etc truth table. Why they put the error code in errno and not in the return code is still a mystery? Too late now to fix it.
jmucchiello
@jmucchiello, yeah i'm wondering too. `0` meaning true and non-`0` false would be nice, i think. Maybe it's less important here though, because in a boolean context, there are only two answers anyway (true and false), so multiple error cases can't be differentiated and for everything else a `switch` is used. The efficient treatment of null pointers with addresses `0x0` maybe are also a concern here. But there would still be the benefit of having the implicit conversion of `0` to `true` meaningful and the truth tables in sync.
Johannes Schaub - litb
Personally, I'd use nonzero as the failure indicator for my internal APIs as well for the same reason. Then, instead of asking the question "did I succeed"? I ask the question "did I fail"?. True/False have no semantic meaning when it comes to error codes.
Billy ONeal
+3  A: 

Generally the return values for any given program tend to be a list (enum) of possible values, such as Success or specific errors. As a "list", this list generally tends to start at 0 and count upwards. (As an aside, this is partly why the Microsoft Error Code 0 is ERROR_SUCCESS).

Globally speaking, Success tends to be one of the only return values that almost any program should be capable of returning. Even if a program has several different error values, Success tends to be a shared necessity, and as such is given the most common position in a list of return values.

It's just the simplest way to allow a most common return value by default. It's completely separate from the idea of a boolean.

KevenK
+1  A: 

Here's the convention that I'm used to from various companies (although this obviously varies from place to place):

  • A negative number indicates an error occured. The value of the negative number indicates (hopefully) the type of error.
  • A zero indicates success (generic success)
  • A positive number indicates a type of success (under some business cases there various things that trigger a successful case....this indicates which successful case happened).
SOA Nerd
A: 

I, too, found this confusing when I first started programming. I resolved it in my mind by saying, 0 means no problems.

kajaco
+4  A: 

I have to quibble with with Johannes' answer a bit. True 0 is used for success because there is only 1 successful outcome while there can be many unsuccessful outcomes. But my experience is that return codes have less to do with reasons for failure than levels of failure.

Back in the days of batch programming there were usually conventions for return codes that allowed for some automation of the overall stream of execution. So a return code of 4 might be a warning but the next job could continue; an 8 might mean the job stream should stop; a 12 might mean something catastrophic happened and the fire department should be notified.

Similarly, batches would set aside some range of return codes so that the overall batch stream could branch. If an update program returned XX, for instance, the batch might skip a backup step because nothing changed.

Return codes as reasons for failure aren't all that helpful, certainly not nearly as much as log files, core dumps, console alerts, and whatnot. I have never seen a system that returns XX because "such and such file was not found", for instance.

Duck