Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-31 23:35:30
On 1/06/2017 08:17, Niall Douglas wrote:
> 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.
Except empty. value() throws that as an exception. exception() also
throws that as an exception (not returning it), which means that the
programmer can't make that assumption you just claimed.
Maybe that's what you want (as it leads very quickly to empty ==
std::terminate), but it's not consistent with use of empty as a success
return as you've suggested in a few places.
> 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".
From the docs and discussion thus far, this is not the impression I had.
The impression I had was that result<T> should be used everywhere in
inner exception-enabled code by preference (since exceptions should not
be caught, they should be propagated outwards).
And then up at the entrypoint from the sea of noexcept to the
exception-enabled island, that entrypoint (which is itself noexcept)
should return an outcome<> from the result<> of its children or an
internal try-catch to propagate out an exception_ptr. outcome<> is used
almost exclusively within the sea; result<> only rarely (for cases where
an exception cannot occur).
Further up the call stack (back in exception-throwing land) you receive
an outcome<> and immediately unpack and rethrow any exception, or
otherwise go back to returning result<>s.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk