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

On 31/05/2017 14:59, Andrzej Krzemienski via Boost wrote:

2017-05-31 15:45 GMT+02:00 Niall Douglas via Boost : 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/