Re: [review][LEAF] Review of LEAF starts today : May 22 - May 31

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-29 18:58:09

On Fri, May 29, 2020 at 1:10 AM Richard Hodges via Boost <
boost_at_[hidden]> wrote:
>
> Thank you for your response.
>
> On Fri, 22 May 2020 at 21:30, Emil Dotchevski via Boost <
> boost_at_[hidden]> wrote:
>
> > On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost <
> > boost_at_[hidden]> wrote:
> >
> > > - From looking at the tutorial it appears that in order to use this
> > library
> > > I would need to write functions that are interested in catching
errors in
> > > terms of a group of lambdas. Is this correct in general, or is this
> > merely
> > > an artefact of the example code?
> > >
> >
> > The lambdas aren't so much to catch errors, but to access additional
> > information associated with the exception (a-la Boost Exception, but a
lot
> > more efficient and with better syntax). If you just want to catch the
> > exception, you can do a plain old try...catch (of course).
> >
> > and
> > - Does LEAF incur any memory or runtime performance overhead in the
> > non-error case?
>
> I think I understand now. The construct of try_handle_all(lambdas...)  is
> building an "error context" into which later leaf-enabled functions down
> the call stack can emplace error info. The address of this context is
> maintained by logically a separate "context stack" which lives in the call
> stack. To be strictly correct, would it be fair to say that there is
memory
> allocation, it just happens to be on the call stack and therefore requires
> very little book-keeping overhead and no mutual exclusion?

Yes. I meant no dynamic allocation. The minimal bookkeeping is logically
similar to a tuple<optional<E>...>.

> > I do not have open source production code to share, but I could possibly
> > show you some code personally.
>
> This would be helpful.
>
> At the moment, I get the impression that this is a very elegant solution
to
> a problem I don't have. I want to be even handed during the review. It
> would be helpful to see some code from a domain where this solution solves
> a very real problem, or have a domain described where LEAF clearly solves
a
> real problem. For that "Oh Wow!" moment that you have presumably
personally
> experienced.

If I'm not mistaken you said you use Boost Exception. That indicates you do
have the problem that you said LEAF solves more elegantly (and more
efficiently) than Boost Exception.

To be more precise, LEAF is designed to help you communicate _all_ data
needed to handle a given failure, from any scope it is available, to the
correct error handler. It can do this even through layers of uncooperative
APIs.