Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-07-15 23:05:22

On Sat, Jul 15, 2017 at 2:23 PM, Groke, Paul via Boost <
boost_at_[hidden]> wrote:

> > From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37
> > To: boost_at_[hidden]
> >
> > Ah, now I get it, thanks for the explanation. There *might* even be a
> > way to get this to work even without memory allocation in the end
> > (without exception_ptr), but I think this is perhaps missing the point
> > of returning an error object, which is to be able to interact with it.
> > Also, reasonably if you could fit the things you need to create the
> > object into a "small object optimized" buffer, you can probably fit the
> > object itself into the same buffer. Noexcept already has that, it's the
> > result<T> object, however it might be too heavy to return up the call
> > chain one level at a time (it is instead designed for capturing the TLS-
> > stored object to postpone its handling, perhaps after moving it to
> > another thread).
>
> The question is: how do you interact with a return value of unknown type?
> For exceptions it's much easier. There is at least the common practice to
> derive your exception from std::exception, so if nothing else, you can at
> least get an error message. And you can catch base classes, which can also
> come in quite handy.
>

It works exactly the same with Noexcept: if you use throw_, the object can
always be intercepted as either std::exception or boost::exception, the
former is useful in the case you need to handle an error no matter its
type, the latter if you want to augment the error object with contextual
data before passing the error up the call chain.