On Fri, May 29, 2020 at 1:10 AM Richard Hodges via Boost < boost@lists.boost.org> wrote:
Thank you for your response.
On Fri, 22 May 2020 at 21:30, Emil Dotchevski via Boost < boost@lists.boost.org> wrote:
On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost < boost@lists.boost.org> 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?
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
Yes. I meant no dynamic allocation. The minimal bookkeeping is logically
similar to a tuple
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.