On 1/28/2016 6:36 AM, Niall Douglas wrote:
On 28 Jan 2016 at 0:49, Michael Marcin wrote:
If the direct caller can handle the error returning an error enum instead of a std::error_code will often be better. It looks like the DXXXXR0 expected proposal allows for this.
The way I've done it is to define a custom error code category per category of error throwing thing, thereby naturally extending C++ 11/Boost error codes. It may seem like an awful lot of boilerplate when you just want an enum really, but trust me that it is worth the effort - you get stuff like free error_code to exception throw to error_code conversions (you specifically need that machinery to return error codes from constructors) and all sorts of other goodies like debug printing. I'd recommend forget about enums for error coding, extend error_code as it was designed to be extended and accept the boilerplate which is fire and forget anyway.
I agree and I make this boiler plate for every error enum I have as well. I find it incredibly useful, in fact I pretty much only throw std::system_error anymore. If you are going to handle the error in non-generic code very close to the caller, I contend there is no need to actually call make_error_code and wrap that enum into a std::error_code. The enum is typically 4 bytes, a std::error_code is usually 16. Certainly many times it doesn't matter at all but there are also times where it would prevent me from having a good faith argument that this is a strict improvement over a more C-style error handling approach.
My dissatisfaction with the quality of output overhead of other solutions led me to invest very significant time into this aspect of Outcome, and there are per-commit unit tests ensuring ideal code quality output for various canned use cases at https://github.com/ned14/boost.outcome/tree/master/test/constexprs.
Thanks for the link. I'll take a look.