Is it a bad idea to mix bool and ret codes

Question

I have some programs which make heavy use of libraries with enumerations of error codes.

The kind where 0(first value of enum) is success and 1 is failure. In some cases I have my own helper functions that return bool indicating error, in other cases I bubble up the error enumeration. Unfortunately sometimes I mistake one for the other and things fail.

What would you recommend? Am I missing some warnings on gcc which would warn in these cases?

P.S. it feels weird to return an error code which is totally unrelated to my code, although I guess I could return -1 or some other invalid value.

Answer 1

Is it a bad idea? No, you should do what makes sense rather than following some abstract rule (the likes of which almost never cater for all situations you're going to encounter anyway).

One way I avoid troubles is to ensure that all boolean-returning function read like proper English, examples being isEmpty(), userFlaggedExit() or hasContent(). This is distinct from my normal verb-noun constructs like updateTables(), deleteAccount() or crashProgram().

For a function which returns a boolean indicating success or failure of a function which would normally follow that verb-noun construct, I tend to use something like deleteAccountWorked() or successfulTableUpdate().

In all those boolean-returning cases, I can construct an easily readable if statement:

if (isEmpty (list)) ...
if (deleteAccountWorked (user)) ...

And so on.

For non-boolean-returning functions, I still follow the convention that 0 is okay and all other values are errors of some sort. The use of intelligent function names usually means it's obvious as to which is which.

---

But keep in mind, that's my solution. It may or may not work for other people.

Answer 2

In the parts of the application that you control, and the parts that make up your external API I would say, choose one type of error handling and stick to it. Which type is less important, but be consistent. Otherwise people working on your code will not know what to expect and even you yourself will scratch you head when you get back to the code in a year or so ;)

Answer 3

If standardizing on a zero == error scheme, you can mix and match both enum and bool if you construct your tests like this:

err = some_func(); if !err...

Since the first enum evaluates to zero and also the success case it matches perfectly with bool error returns.

However, in general it is better to return an int (or enum) since this allows for the expansion of the error codes returned without modification of calling code.

Answer 4

I wouldn't say, that it's a bad practice.

There's no need to create tons of enum-s, if you just need to return true/false, and you don't have other options (and true and false are explanatory enough ).

Also, if your functions are named OK, you will have less "mistakes"

For example - IsBlaBla - expects to return true. If you have [Do|On]Reload, a reload could fail for many reasons, so enum would be expected. The same for IsConnected and Connect, etc.

Answer 5

IMHO function naming helps here.

E.g. for functions that return a boolean value, is_foo_bar(...), or for functions that return success or an error code, do_foo_bar(...).