[review][LEAF] Review of LEAF starts today : May 22 - May 31
The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st. LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance. Every software developer must deal with handling errors which makes this review relevant to all. Please participate! I will be grateful to receive a review based on whatever level of effort or time you can devote. 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. The LEAF documentation highlights the following features: * Efficient delivery of arbitrary error objects to the correct error handling scope. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. * Support for multi-thread programming. "LEAF is designed with a strong bias towards the common use case where callers of functions which may fail check for success and forward errors up the call chain but do not handle them." LEAF offers a pattern matching facility to specify which errors to handle and how to handle them. Take a look at the 5-minute Introduction. <https://zajo.github.io/leaf/#introduction> You can find the source code to be reviewed here: <https://github.com/zajo/leaf/tree/review> You can find the documentation here: <https://zajo.github.io/leaf/> The documentation includes a tutorial, examples, reference, design rationale, and comparisons to other error handling approaches/libraries. There is a benchmark document also: <https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md> and a whitepaper: <https://github.com/zajo/leaf/blob/master/doc/whitepaper.md> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including LEAF as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? 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
-----Original Message----- From: Boost-users <boost-users-bounces@lists.boost.org> On Behalf Of Michael Caisse via Boost-users Sent: 22 May 2020 10:32 To: Boost users list <boost-users@lists.boost.org> Cc: Michael Caisse <mcaisse-lists@ciere.com> Subject: [Boost-users] [review][LEAF] Review of LEAF starts today : May 22 - May 31
The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error Augmentation Framework) library will take place from May 22 through May 31st.
LEAF isn't just another error reporting library in the family of expected-like types. It provides a unique take on error handling which plays into usability, flexibility, and performance.
Some other questions you might want to consider answering:
- What is your evaluation of the design?
Above my pay-grade, but looks reasonable.
- What is your evaluation of the implementation?
Above my pay-grade, but looks as though it works OK from examples and user experience. Feels refined and the product of much work.
- What is your evaluation of the documentation?
Outstanding. Excellent.
- What is your evaluation of the potential usefulness of the library?
I'm sure some people will find it useful.
- Did you try to use the library?
I didn't try to use it - because I am not too unhappy with 'simple' try'n'catch exception programming.
- How much effort did you put into your evaluation?
I've read, and re-read the documentation and examples, and all the reviews.
- Are you knowledgeable about the problem domain?
No - but the Big Thing I know is that the Less-expected Doesn't Work Well. <rant> * The hardware seems little help - bounds like containers are only available slowly and painfully. * The software seems to have to be either fast and unhelpful, or slightly helpful at major computational cost (C++ exceptions). * The programmers are idle and unhelpful. How my blood pressure has been raised by shouting "Which file?" to "File not found."! * Too much give-up quickly "Something went wrong." Call C++ std::terminate ☹ * OK - enough - everyone agrees that things are not good. </rant> LEAF isn't The Silver Bullet, but clearly is reasonable way of doing things, and well done. So the problem for Boost is whether to reject it on grounds that better ways exists, or accept it as a useful tool, helpfully documented. It raises the number of ways for doing these things from perhaps three to four, but that's not much worse - it just is confusing. (I am not over concerned at Boost Bloat - it is only programmers disk space that is idle/wasted. We MUST sell that better!) So in the end I conclude that it turns on deciding if Boost should offer a choice tools, or should it make a single recommendation? I see no case for any one Best Exceptions Tool, so I believe that we should ACCEPT LEAF. Paul A. Bristow
On Tue, Jun 2, 2020 at 9:49 AM Paul A. Bristow via Boost-users < boost-users@lists.boost.org> wrote: Thanks for the review.
It raises the number of ways for doing these things from perhaps three to four, but that's not much worse - it just is confusing.
It's reasonable to look at it this way, but in one specific aspect it's going from zero to one. Many error handling interfaces aim at unifying usage. For example, std::error_code could be THE one and only way error codes are communicated, but this hasn't happened, and it won't happen. The reason is that if error object types participate in function signatures, even functions that don't handle errors become coupled with them. It becomes impossible to write functions that are _neutral_ towards error handling. The result is a diversity of types and interfaces, as different programmers, correctly, avoid coupling most of their functions with what they consider external APIs. Exception does not suffer from that problem: _neutrality_ is not only possible, but it is the default for any function that doesn't handle exceptions. LEAF provides much of this _neutrality_, minus the overhead of memory allocations and dynamic casts of exception handling. I am not aware of another alternative.
participants (1)
-
Emil Dotchevski -
Michael Caisse -
pbristow＠hetp.u-net.com