Re: [boost] Error handling libraries and proposals

Subject: Re: [boost] Error handling libraries and proposals
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-10 18:42:44

On Mon, Jul 10, 2017 at 10:44 AM, Niall Douglas via Boost <
boost_at_[hidden]> wrote:

> On 10/07/2017 18:07, Emil Dotchevski via Boost wrote:
> > Last week it was brought to my attention that there are currently 5
> > different libraries and proposals for dealing with the problem of
> reporting
> > errors from noexcept functions, so I thought it would be useful to update
> > the Noexcept documentation with a short section comparing all the
> different
> > designs: https://zajo.github.io/boost-noexcept/#alternatives.
>
> Some notes on Outcome v2 related to your now out of date comparison:
>

Thank you for letting me know that the Outcome design has changed, again. :)

> * result and outcome can now be error type customised, same as all the
> other libraries.

Not all the other libraries. The Noexcept design does not force you specify
the possible error types for each function because, as we have learned from
the exception specifications fiasco, in non-trivial cases (usually in
generic library code) it is impossible to know what errors may be returned
by lower level functions. If the error handling library forces you to list
them anyway, in such use cases the two choices you're left with is to
translate (which is prone to errors and usually imperfect), or some form of
catch-all, e.g. unique_ptr<void>.

The reality is that not everyone is or will be using only std::error_code;
ideally, functions should be able to forward errors from lower level code
intact.

> For example, outcome<void, void, void> is legal, though
> unusable.
>

What would be the meaning of outcome<void,void>?

>
> , but for Outcome v2 the new values are:
>
> yes, yes, yes, yes, no, yes, yes, yes.
>

To me, your note that Outcome is struct-like rather than variant-like means
that it does not have strict value-or-error semantics, so the last one
would be "no". Also, could you expand on how Outcome can propagate errors
from a C-style callback or across language boundaries? I'm referring to use
cases like these: https://zajo.github.io/boost-noexcept/#example_lua