From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-05-22 19:30:23
On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost <
> - 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).
> - Furthermore, it seems that any function which may produce an error
> (previously an exception) or pass one down the caller chain, would need to
> be rewritten in terms of the LEAF macros and return types. Is this correct,
> or have I misunderstood?
You misunderstood. If you use exceptions, you don't need a result<T> type
or LEAF_AUTO. You probably got confused because the initial introduction
starts with a result<T> example, but it continues with the same example
With exceptions: https://zajo.github.io/leaf/#introduction-eh
With result<T>: https://zajo.github.io/leaf/#introduction-result
> - It would be interesting to me to see a real program, that sees production
> use, written in terms of LEAF in order to assess the maintenance and
> readability impact of this. Is there an example of one available?
I do not have open source production code to share, but I could possibly
show you some code personally. You mentioned Boost Exception, perhaps
you'll find this section helpful:
https://zajo.github.io/leaf/#boost_exception. Switching from Boost
Exception to LEAF is straight-forward (and generally recommended).
> - Does LEAF incur any memory or runtime performance overhead in the
> non-error case? If so what is the impact of this when compared to the
> itanium zero-cost exception handling ABI?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk