Question

Very often you have a function, which for given arguments can’t generate valid result or it can’t perform some tasks. Apart from exceptions, which are not so commonly used in C/C++ world, there are basically two schools of reporting invalid results.

First approach mixes valid returns with a value which does not belong to codomain of a function (very often -1) and indicates an error

int foo(int arg) {
    if (everything fine)
        return some_value;
    return -1; //on failure
}

The scond approach is to return a function status and pass the result within a reference

bool foo(int arg, int & result) {
     if (everything fine) {
         result = some_value;
         return true;
     }
     return false;  //on failure
}

Which way do you prefer and why. Does additional parameter in the second method bring notable performance overhead?

Answer 1

Don’t ignore exceptions, for exceptional and unexpected errors.

However, just answering your points, the question is ultimately subjective. The key issue is to consider what will be easier for your consumers to work with, whilst quietly nudging them to remember to check error conditions. In my opinion, this is nearly always the “Return a status code, and put the value in a separate reference”, but this is entirely one mans personal view. My arguments for doing this…

1. If you choose to return a mixed value, then you’ve overloaded the concept of return to mean “Either a useful value or an error code”. Overloading a single semantic concept can lead to confusion as to the right thing to do with it.
2. You often cannot easily find values in the function’s codomain to co-opt as error codes, and so need to mix and match the two styles of error reporting within a single API.
3. There’s almost no chance that, if they forget to check the error status, they’ll use an error code as if it were actually a useful result. One can return an error code, and stick some null like concept in the return reference that will explode easily when used. If one uses the error/value mixed return model, it’s very easy to pass it into another function in which the error part of the co-domain is valid input (but meaningless in the context).

Arguments for returning the mixed error code/value model might be simplicity – no extra variables floating around, for one. But to me, the dangers are worse than the limited gains – one can easily forget to check the error codes. This is one argument for exceptions – you literally can’t forget to handle them (your program will flame out if you don’t).