|
Boost : |
Subject: Re: [boost] LEAF has been refactored, it now has a much simplified error handling interface
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-01-23 22:06:26
On Wed, Jan 23, 2019 at 11:47 AM Sorin Fetche via Boost <
boost_at_[hidden]> wrote:
>
> On Wed, Jan 23, 2019, 2:07 AM Emil Dotchevski via Boost <
> boost_at_[hidden] wrote:
>
> > Thank you for testing.
> >
> > I fixed the first assert, I hadn't tested catch_<> when there is no
> > exception. It works now.
> >
>
> I'm trying to evaluate how the LEAF library would work for transporting
> additional information besides error codes when implementing Asio
> asynchronous operations.
>
> So, my next test is to capture both errors and exceptions together with
> additional info and pass them to the completion handler that will do a
> detailed error analysis.
>
> I have two unsuccessful attempts at this on wandbox (together with
> leaf/all.hpp merged in a single file by a little Python script):
>
> - with try_:
> https://wandbox.org/permlink/t0r0IUntnga6zUUK
>
> - with capture_result:
> https://wandbox.org/permlink/OCfmA9WXEgSySE1E
>
> Any suggestions on how to change the test(s) to achieve this?
> Would this be a use case supported (efficiently, when no error occurred)
by
> the LEAF library?
Yes, I should put this in FAQ in the documentation because it is subtle yet
critical.
This is correct:
leaf::try_(
[ ]() -> leaf::result<T>
{
return do_work(); //but usually the do_work body goes here, rather than
a single function call.
},
..... //handlers
);
This is incorrect:
leaf::result<T> r = do_work();
leaf::try_(
[r]() -> leaf::result<T>
{
return r;
},
..... //handlers
);
The problem is that the memory where any errors reported to LEAF by do_work
will be moved to is in the scope of leaf::try_, so anything that happens
before you enter leaf::try_ won't be captured by *this* leaf::try_, but by
some *other* leaf::try_, leaf::handle_some, or leaf::handle_all scope up
the call chain, if any. You can _almost_ forget that leaf::result<T>
doesn't contain any actual error objects... but not quite. :)
If you haven't already, you can look at example/capture_eh.cpp and
example/capture_result.cpp, they demonstrate the canonical way to transport
error objects across threads.
Let me know if I can help more.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk