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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
> 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
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost <
[hidden email]> 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).


> - 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
using exceptions:

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

Generally, no.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
I notice that the LEAF documentation comes with benchmarks comparing
leaf::result to other return-based error handling systems.  That's good.

But I also notice that it doesn't come with benchmarks comparing
exception-based LEAF with other exception-based error handling systems
like Boost.Exception.  Nor does it come with benchmarks comparing
leaf::result with leaf::exception.  That's less good.

I am currently using Boost.Exception, and I am satisfied with its
functionality, but I am worried about its performance cost.  LEAF claims
to be a faster functional replacement for Boost.Exception, and is for
this reason seems worth investigating.  However, this claim does not
appear to be backed up by any hard numbers.


--
Rainer Deyke ([hidden email])


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Sun, May 24, 2020 at 1:14 AM Rainer Deyke via Boost <
[hidden email]> wrote:
>
> I notice that the LEAF documentation comes with benchmarks comparing
> leaf::result to other return-based error handling systems.  That's good.

By the way, to use LEAF without exceptions, you don't have to use
leaf::result. For example, if you have a program that generally
communicates failures in terms of some other result<T>, usually you need
not change that in order to utilize LEAF to transport additional error
objects when needed.

As for the benchmark, it is not very fair to LEAF: it only tests the
performance when transporting a single error object. The killer feature of
LEAF is the ability to efficiently associate with a single failure any
number of error objects, of arbitrary types. To do this with another result
type, you'd have to allocate memory dynamically.

> I am currently using Boost.Exception, and I am satisfied with its
> functionality, but I am worried about its performance cost.  LEAF claims
> to be a faster functional replacement for Boost.Exception, and is for
> this reason seems worth investigating.  However, this claim does not
> appear to be backed up by any hard numbers.

Thank you for using Boost Exception. The claim that LEAF is faster is based
on the fact that Boost Exception allocates error objects dynamically and
keeps them organized in a std::map (stored in the exception object itself),
while LEAF keeps all error objects in a std::tuple stored in the stack
frame of the error-handling function that needs them (e.g. where the
try...catch is).

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost