Boost logo

Boost :

Subject: Re: [boost] [outcome] Change semantics on UB from peer review agreed semantics?
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-09-13 01:58:01


On 13/09/2018 12:54, Peter Dimov wrote:
> However, I vaguely remember that I convinced myself at one point that
> the latter (calling a function to convert) is inferior to calling a
> function that throws. For one thing, you can't convert an exception_ptr
> to an exception (*); for another, sometimes you want to throw different
> exceptions based on the runtime value of the error code (bad_alloc on
> ENOMEM for instance.)

True. I did start writing the email that way, but along the way thought
that it might be a good idea to require use of boost::throw_exception
via a return value (and thus getting a return-type trait for "free").

But you're right that there are some cases that don't work as well that
way, since value returns aren't polymorphic.

> (*) This is needed, for instance, when you build an outcome<> on top of
> a result<> by
>
> struct my_error_code
> {
>    std::error_code code_;
>    std::exception_ptr exc_;
> };
>
> template<class T> using outcome = result<T, my_error_code>;

Arguably that sort of construction ought to "unpack" the error into the
three-type outcome<T, my_error_code_without_exception, exception_ptr>.
Other than interop with pre-Outcome code I would think that such cases
should be fairly rare.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk