Re: [boost] [outcome] High level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-01 08:20:50

2017-05-31 22:17 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> On 31/05/2017 14:59, Andrzej Krzemienski via Boost wrote:
> > 2017-05-31 15:45 GMT+02:00 Niall Douglas via Boost <
> boost_at_[hidden]>:
> > Errors -- usual failure, Exceptions -- exceptional failure. Ok. But when
> I
> > call `error()` it is like saying "tell me if a *usual* failure ocurred",
> I
> > get no exception, fine. When I call `exception()` it is like saying "tell
> > me if an *exceptional* failure ocurred", and you are giving me a
> > non-exceptional one.
> >
> > This does not (yet) sound consistent to me.
>
> It makes sense when one assumes that outcome<T> accumulates result<T>,
> which it does. Outcome's design assumes that all outcome types
> eventually end up in an outcome<T>.
>
> The programmer, when working with outcome<T>, knows that calling
> .exception() will return the exact same exception as would be thrown
> when calling .value(), thus saving wrapping .value() in a try...catch
> just to capture the exception_ptr emitted.
>

Ok, this is important. And not obvious from the docs. But I do not think it
is true in the face of the potential empty state.

>
> The actually odd one out here is .error(), as Emil correctly spotted. It
> is there basically for the programmer to more efficiently intercept when
> an error code to exception throw conversion would occur, which is
> expensive.
>
> So, for outcome<T>, start with assuming that .value() and .exception()
> fully represent the twin sides of behaviour, and .error() is an early
> out mechanism.
>
> For result<T>, it's basically a castrated outcome<T> used only for
> performance sensitive code, or rather, to say "this function takes
> performance very seriously".
>

Is it also true that when I call `exception()` it will give me the
error_code_extended wrapped into an exception_ptr, if there is one?

>
> Does this make more sense?
>

This is my current understanding: When inspecting `outcome`, I should use
`exception()` to get information about any "failure" (either reported by
exception_ptr or by error_code_extended). Function `error()` is either for
performance or to discriminate between exception_ptr or by
error_code_extended.

Did I get it right?

(I hope so, and note that in order to describe that one does not have to
say that "some failures are expected, and others are not expected")

Regards,
&rzej;