Boost logo

Boost :

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

Thanks for the link. I'll take a look.

Boost list run by bdawes at, gregod at, cpdaniel at, john at