returned error code

[iu2]

Hi all,
I'm interested in your experience with returned error codes:
What's better, return true/false for success/fail, or return 0 for Ok
and a negative for failure?
This question arose since in my project we use both systems, which led
to a bug of misinterpreting returned code (a function retured 0 for
success but the programmer treated it as false).

The 0/negative system has been suggested to allow a range of failure
codes. But practically we almost don't analyze them. Feeling that I
shoud be thankful for handling and reporting error at all, I thought
of getting rid of 0/negative system and work only with true/false.
This also produces shorter code:
"if (SomeFunc())" instead of "if (SomFunc() == 0)" (or even worse,
due to tidy programming
"if (SomeFunc() == code_ok)").

What do you say?
Thanks

 

[FabioAng]

Hi all,
I'm interested in your experience with returned error codes:
..., or return 0 for Ok and a negative for failure?

That's the Unix sytle and I think it's a valid one.

This question arose since in my project we use both systems, which led
to a bug of misinterpreting returned code (a function retured 0 for
success but the programmer treated it as false).

The 0/negative system has been suggested to allow a range of failure
codes. But practically we almost don't analyze them. Feeling that I
shoud be thankful for handling and reporting error at all, I thought
of getting rid of 0/negative system and work only with true/false.

Why don't you want to use exceptions ?
http://www.boost.org/more/generic_exception_safety.html

Fabio

 

[James Kanze]

I'm interested in your experience with returned error codes:
What's better, return true/false for success/fail, or return 0 for Ok
and a negative for failure?

Neither. You really need to use an enum:

enum ErrorStatus
{
ok,
someError,
someOtherError
} ;

This question arose since in my project we use both systems, which led
to a bug of misinterpreting returned code (a function retured 0 for
success but the programmer treated it as false).

Precisely. The same problem exists for true/false: does true
mean success, or failure. If you have to compare with a
symbolic constant, like ok, the problem can't occur.

The 0/negative system has been suggested to allow a range of failure
codes. But practically we almost don't analyze them. Feeling that I
shoud be thankful for handling and reporting error at all, I thought
of getting rid of 0/negative system and work only with true/false.
This also produces shorter code:
"if (SomeFunc())" instead of "if (SomFunc() == 0)" (or even worse,
due to tidy programming
"if (SomeFunc() == code_ok)").

Shorter doesn't always mean more readable or more
understandable. This is one case where longer is better.

 

[iu2]

That's the Unix sytle and I think it's a valid one.



Why don't you want to use exceptions ?http://www.boost.org/more/generic_exception_safety.html

Fabio

I'd like to but:
1. It's too late for my project now...
2. In some cases I don't want an exception. For example something
fails, but I want to respond only after x successive failures. Then
each single failure should realy return an error code (I think) and
somewhere higher in the calling path I count the failures.

iu2

 

[Roland Pibinger]

Precisely. The same problem exists for true/false: does true
mean success, or failure. If you have to compare with a
symbolic constant, like ok, the problem can't occur.

Naming conventions are helpful in such cases. Functions that start
with is... or has... are supposed to answer a question, e.g.

bool isConnected (DBConnection& dbc);

 

[James Kanze]

Naming conventions are helpful in such cases. Functions that start
with is... or has... are supposed to answer a question, e.g.

bool isConnected (DBConnection& dbc);

That's a different issue. I wouldn't say that a function like
"isConnected" failed. It returns status information. (Almost
by definition, a function whose name starts with "is" returns a
bool.) On the other hand, if the function name is
"isConnected", it should almost certainly be const, and not try
to establish a connection (which might fail). And the meaning
of a bool return value of a function named "establishConnection"
is ambiguous.