This latter "idiom" is obviously broken after NIall's suggested change though.
Maybe. It depends. If your category defines 0 as success, then if(err) will return false, as it should be. If your code does: err.assign(0, err.category()); if(err != error_code()) ... And if your category is system_category, then yes now you would be broken, because a default constructed error code would have a null category under my proposal. Not system_category as at present. One could dispense with null_category, and use system_category, but with an internal nullptr representation. My objection to that is that C++ 11 is assuming that on every possible OS out there, code 0 is always success. I find that to be presumptuous, and I think it should be fixed.
I'm also not happy to have to convert that initialization to
err = error_code();
because it loses information about the error category, which may be useful if I want to print `err` to log even if it is a success.
Interesting. You rely on there being different success error_codes? This is also in direct opposition to the requested change.
No, every code domain must be allowed to dictate what means success to it.
For example, NTSTATUS code have two degrees of success, and two degrees
of failure. The top two bits determine this, leaving 30 bits for values
of each degree. An ntkernel_category would therefore define all codes
with a value >= 0 as being success.
Note that right now under the present design, we cannot represent this
in
How would you suggest we solve the problem of zero being an error in some contexts?
I think the same way as all non-negative values being a success. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/