On Tue, Jun 13, 2017 at 11:01 AM, Peter Dimov via Boost < boost@lists.boost.org> wrote:
Emil Dotchevski wrote:
If error codes are treated as "the error", then the error domain is limited to a single function. Consider these two functions:
int f1(....); //returns 0 on success, 1-f1_error1, 2-f1_error2 int f2(....); //returns 0 on success, 1-f2_error1, 2-f2_error2
If f2 calls f1, if the error is communicated by an error code, f2 _must_ translate the error condition from the domain of f1 errors, to the domain of f2 errors. And this must be done at every level, which introduces many points in the code where subtle errors may occur, and that is in error handling code which is very difficult to test and debug.
That's exactly the problem std::error_code solves, as it's a (code, domain) pair, so there's no need to translate.
That presumes that ENOENT represents the same _error_ when returned from two different functions. Generally, it does not. The correct strategy in C++ is to throw different types to indicate different errors, even when both end up carrying the same ENOENT. So it is critical to decouple the error code (std or otherwise) from _what_ went wrong, and if you don't, you're butchering the ability to write error-neutral functions, which in practice means translating error codes from one domain to another, at every level, which is prone to errors.