Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2016-01-28 11:32:06

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.