Let's simply start with some code, provided by Adam:

static bool Failed(bool value)
{
    return value;
}

Now, you look at this method, and you ask yourself, "what use is this?" Well, scattered through the codebase, you can see it in use:

bool bOK;
bOK = someProcessWhichMightFail();
return bOK ? true : Failed(false);

Adam went through the commit history and was able to get a sense of what the developer was actually trying to do. You see, in some places, there are many reasons why the call might fail. So by wrapping a method around the kind of failure, you had a sense of why it failed, for example, it could be return bOK ? true : FILE_NOT_FOUND(false);

Now, you know why it failed. Well, you know why if you read the code. As this is C++, one could have communicated failure states using exceptions, which would be more clear. If you wanted to stick to return codes for some calling convention reason, one could use enums. Or a pile of #defines. Pretty much anything but this.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!