Boost logo

Boost :

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2020-05-22 10:51:09


> LEAF is brought to us by Emil Dotchevski, the author of Boost.Exception.
> Similar to Boost.Exception, this library allows arbitrary error objects
> to be returned; however, unlike Boost.Exception it does not require
> dynamic memory. The library can be used with or without exception handling.
>
>
This response is in the form of exploratory questions to the author, which
I hope will aid my evaluation.

Disclaimer: At present I am one of the few people in the world who uses
nested exception handling (similar to boost.exception) in production
programs for reasons of:
- efficiency in the non-exception case
- readability (not mixing error handling concerns with logic concerns)
- ambivalence about the cost of memory allocation or dynamic lookup in the
rare case of an exception being thrown
- collection of all data that led to the cause of the exception, without
having to collect a stack trace

Questions are being asked from the basis of deciding whether there would be
an advantage in switching to LEAF.

The LEAF documentation highlights the following features:
>
> Some other questions you might want to consider answering:
>
> - What is your evaluation of the design?
>

Early to say, but I have some questions.

- 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?

- 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?

- 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?

- 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?

> - What is your evaluation of the implementation?
>

Not yet ascertained.

> - What is your evaluation of the documentation?
>

Clear, friendly and complete.

> - What is your evaluation of the potential usefulness of the library?
>

TBA

> - Did you try to use the library? With which compiler(s)? Did you
> have any problems?
>

No

> - How much effort did you put into your evaluation? A glance? A quick
> reading? In-depth study?
>

Detailed reading of the tutorial, careful consideration of what I perceive
to be the impact of adoption based on that reading.

> - Are you knowledgeable about the problem domain?
>

Yes

>
> More information about the Boost Formal Review Process can be found
> here: <http://www.boost.org/community/reviews.html>
>
> Thank you for your effort in the Boost community.
>
> Happy coding -
> michael
>
> --
> Michael Caisse
> Ciere Consulting
> ciere.com
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Richard Hodges
hodges.r_at_[hidden]
office: +442032898513
home: +376841522
mobile: +376380212

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk