Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-13 18:09:55
On Thu, Jul 13, 2017 at 3:16 AM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:
> > I didn't mean that you would design the program like this, the point is
> > that you may not have control over the fact that foo returns EC1, and you
> > still have to be able to write bar() (I should have made that clearer by
> > using different namespaces.)
> >
> > In this comment you're echoing what Niall was saying in the documentation
> > of the original Outcome, where he had several paragraphs attempting to
> > convince the reader to stop using random error codes and _always_ use
> > std::error_code, with technical phrases like "don't be anti-social" :)
> >
> > But that is not our reality, and it will never be our reality in C++
> > because C++ programs do use C libraries, and because different C++
> > libraries commonly use their own types for similar things. This is
> > especially true for error codes.
>
> I just don't see this argument.
>
> If you're facing multiple third party C libraries each with their own
> error coding, that's exactly what std::error_code is there to handle
> non-intrusively.
>
If std::error_code is sufficient, put your money where your mouth is and go
back to outcome v1 where the only choices were std::error_code and
std::exception_ptr. But the reality is that std::error_code is not
sufficient (perhaps not due to its own deficiencies); in practice you do
need to be able to transport more or less arbitrary error types.