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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 20:17:43

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.

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".

Does this make more sense?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/