[review][LEAF] Review of LEAF

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

[review][LEAF] Review of LEAF

Boost - Users mailing list
On Fri, May 22, 2020 at 2:37 AM Michael Caisse via Boost
<[hidden email]> wrote:
>
> The Boost formal review of Emil Dotchevski's LEAF (Lightweight Error
> Augmentation Framework) library will take place from May 22 through May
> 31st.

I wholeheartedly recommend ACCEPTing LEAF as a Boost library

I base my recommendation on both the qualities of the library itself
and the responsiveness and openness for feedback of its author.

As a background, more than year ago, I evaluated error handling using
LEAF in the context of an in-house support library for implementing
C++ RESTful services.

I consider the error handling for microservices based architectures
very important because it needs to cover two, sometimes competing,
requirements:
- as debug logs are less than ideal in distributed systems, an error
condition should capture and carry with it as much context and debug
information as possible as it propagates back across the stack (both
in-process and across different processes/services);
- the end-user of the system should not just get a dump of meaningless
debug information when an error condition occurred (but neither just a
generic "internal error occurred" one).

And, coming from the experience of using Boost.Exception for an
earlier version of such a utility library, LEAF seemed a very good
candidate.

So, as part of this evaluation, I tried to see how it would fit
alongside Boost.Asio and Boost.Beast in building this REST oriented
scaffolding. Through the course of this experimentation, LEAF improved
its support for being used with Asio style asynchronous operations and
multi-threading. It also includes now an example built at that time
that showcases a possible way for how this integration can be be
achieved.


>   - What is your evaluation of the design?

Excellent as it allows bridging multiple error handling strategies and
usage patterns in an efficient way. I view it as a clear successor to
Boost.Exception and has very good interoperability with Boost.Outcome.

>   - What is your evaluation of the implementation?

I have not studied it in depth but from what I can tell, as a user of
the library, it is very solid.


>   - What is your evaluation of the documentation?

Excellent!

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

It might not cover any possible usage scenario with error reporting
and handling being such a generic problem space that often has
conflicting requirements, but for sure it covers enough of it to
warrant its inclusion in Boost.

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

Yes, extensively last year. Less so, recently [*]
Tried it with Visual Studio 2019, g++ 7.3 and 8.2, clang 7.0

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

In depth study and usage about an year ago.
Following the changes it has suffered  since then (nothing significant
from what I can tell).

>   - Are you knowledgeable about the problem domain?
>

I have used multiple error handling libraries over time.
And, I also had to deal with distributed systems that had an improper
or lacking error handling design, something simply slapped on as an
afterthought.


[*] The part of the project requiring C++ based services and by
extension the infrastructure to enable writing them has been postponed
as we (the team I'm part of) focused more on the environment where
these services would run. I expect we'll resume this work sometime
later this year. And at that time we'll start using the LEAF library
again.

Best regards,
Sorin Fetche
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list
On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users <[hidden email]> wrote:
> Excellent as it allows bridging multiple error handling strategies and
> usage patterns in an efficient way. I view it as a clear successor to
> Boost.Exception and has very good interoperability with Boost.Outcome.

Thanks for highlighting this. Indeed, you can use outcome::result<> instead of leaf::result<>, and still use LEAF to handle errors; it does not have to replace any library already in use, it could be deployed surgically in a large code base, to get error objects transported in a tricky case or two.

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list
On 31/05/2020 00:43, Emil Dotchevski via Boost-users wrote:

> On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users
> <[hidden email] <mailto:[hidden email]>> wrote:
>> Excellent as it allows bridging multiple error handling strategies and
>> usage patterns in an efficient way. I view it as a clear successor to
>> Boost.Exception and has very good interoperability with Boost.Outcome.
>
> Thanks for highlighting this. Indeed, you can use outcome::result<>
> instead of leaf::result<>, and still use LEAF to handle errors; it does
> not have to replace any library already in use, it could be deployed
> surgically in a large code base, to get error objects transported in a
> tricky case or two.

I should add that those who use Experimental Outcome do so because
status_code can transport arbitrary payload in the result's E type. If
the payload is non-trivial, a common strategy is to store it in a
singleton, and pass a unique identifier to that item in the singleton in
the payload. This is not dissimilar to the technique which LEAF provides.

Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list
In reply to this post by Boost - Users mailing list

On Sat, 30 May 2020 at 18:44, Emil Dotchevski via Boost-users <[hidden email]> wrote:
On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users <[hidden email]> wrote:
> Excellent as it allows bridging multiple error handling strategies and
> usage patterns in an efficient way. I view it as a clear successor to
> Boost.Exception and has very good interoperability with Boost.Outcome.

Thanks for highlighting this. Indeed, you can use outcome::result<> instead of leaf::result<>, and still use LEAF to handle errors; it does not have to replace any library already in use, it could be deployed surgically in a large code base, to get error objects transported in a tricky case or two.

Is there scope for merging LEAF and Outcome as it seems from (very detailed discussions) that they only partially overlap? I don't think that 'we' should keep on adding distinct libraries that partially overlap, Existing libraries should be expanded instead, and deduplication should be done in a coordinated way (in this case between LEAF and Outcome). Something has to be done to stop exponential growth of Boost while maintaining flexibility to add code at will.

With 20/20 hind-sight, I think that Boost.Outcome was wrong as a name and should have been called Boost.Error or something and both LEAF and Outcome could (if only) now live in that space. Adding code to Boost should not lead to an ever increasing difficulty of choosing the right tool for the right job for end-users.

The discussions here are very detailed but to the casual user that's most probably all lost because (luckily) not all will be reflected in the manual and not all users will have the level of expertise of Boost library authors or time to study the documents extensively. The typical end-user will not be able to make a choice and will make the choice to move on to a 3rd party library where the first line of the read.me reflects his/her exact problem and use-case and proposes a solution to this exact problem.

As C++ already has exceptions (and will have exceptions light in the future), the use-case you presented to use LEAF surgically with C-api's seems convincing (it presents a better case than the case of generically re-working an exception system that works, is fundamental to C++ and is promised to be improved in the future, i.e. it's the safest bet. Any library is secured till maintenance ceases, the language/STL (exceptions, exceptions light) is a pdf-file (i.e. future proof by default).

degski

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


--
@systemdeg
"We value your privacy, click here!" Sod off! - degski

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list
On 01/06/2020 12:51, degski via Boost-users wrote:

> Is there scope for merging LEAF and Outcome as it seems from (very
> detailed discussions) that they only partially overlap?

My own opinion:

1. You may remember that Emil was one of two people who voted to reject
Outcome back during its review, as he felt that it was the wrong design.
His comments on what would be better back then map well onto what he has
presented in LEAF. I find that very reasonable: (i) he thought he could
do better (ii) he went ahead and did better in his opinion (iii) he is
presenting now what he thinks is better, and is asking Boost for its
opinion on whether he improved things or not.

2. There is long established precedence for Boost containing multiple
libraries that approach a problem from multiple perspectives e.g. we
currently have three error handling libraries, four maths libraries etc.
If LEAF were accepted, you'd now have four instead of three error
handling libraries. And that seems to me just fine, and not out of
precedence.

3. I specifically and deliberately chose to not design Outcome like
LEAF. I thought then, and I still do, that Outcome ought to be great at
all the things no other solution is great at. I think I succeeded on
that. As I already stated in my own review of LEAF, I personally think
that there is already a perfectly good implementation of LEAF shipping
in any C++ compiler of the past twenty years. I don't, personally
speaking, see the value add for choosing LEAF over C++ exceptions except
to tick some box called "C++ exceptions globally disabled compatible".

> I don't think
> that 'we' should keep on adding distinct libraries that partially
> overlap, Existing libraries should be expanded instead, and
> deduplication should be done in a coordinated way (in this case between
> LEAF and Outcome). Something has to be done to stop exponential growth
> of Boost while maintaining flexibility to add code at will.

The best way to stop exponential growth of Boost, if that is desirable,
is to start culling libraries that aren't maintained nor useful. Or at
least publish a documented list of libraries that new code ought to not use.

> As C++ already has exceptions (and will have exceptions light in the
> future), the use-case you presented to use LEAF surgically with C-api's
> seems convincing (it presents a better case than the case of generically
> re-working an exception system that works, is fundamental to C++ and is
> promised to be improved in the future, i.e. it's the safest bet. Any
> library is secured till maintenance ceases, the language/STL
> (exceptions, exceptions light) is a pdf-file (i.e. future proof by default).

The current formulation of lightweight exceptions before WG21 is
literally Experimental Outcome in language form. Same proposed error
object, std::error. It is currently expected that both value-based and
type-based exceptions would exist in future C++, in order to retain
backwards compatibility, as the semantics between the two are not
currently believed possible to be made exactly one-one.

Experimental Outcome works fine in C code, same as how the most recent
proposal for lightweight exceptions also supports C.

Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list
On 01/06/2020 14:48, degski wrote:

>
> On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     The current formulation of lightweight exceptions before WG21 is
>     literally Experimental Outcome in language form. Same proposed error
>     object, std::error. It is currently expected that both value-based and
>     type-based exceptions would exist in future C++, in order to retain
>     backwards compatibility, as the semantics between the two are not
>     currently believed possible to be made exactly one-one.
>
>
> i am obviously oblivious to what 'is in front of', but knowing that now
> [what light weight exceptions entails], I concur with you. As I noted in
> that same post, I 'get' [in respect of LEAF] the use-case of a c-api
> error-handler (but there must be plenty of those, no?), but otherwise I
> don't see it. From my personal perspective, I would not hesitate one
> second to use Outcome now, instead of any other solution better, or
> worse, just because it is going to be in some shape or form, but very
> similar, in the future standard.

Just so nobody misinterprets anything, right now EWG is not keen on
proposed lightweight exceptions. Microsoft hopes to modify MSVC to
support an implementation in the near future, and that may change EWG's
opinion.

LEWG is keen, so far, on the library side of things i.e. std::error and
the wider status_code machinery. We recently ported a large codebase at
work from <system_error> to status_code. It took about a day, and the
status_code edition is considerably more flexible and useful (mainly
thanks to that custom payload feature, and strongly typed code objects).
The ability to quickly wrap custom enums into custom status code domains
is a nice timesaver too. I should stress though that status_code
natively recognises std::error_code, it automatically wraps any custom
std::error_category into a synthesised custom status_code_code, so you
can totally mix the two in the same codebase, and it'll all "just work".

Current committee direction is that C++ 23 should get std::error and a
implementation of Outcome's result<T> as std::result<T>, with E
hardwired to any type deriving from std::error. This isn't as good as
lightweight exceptions, but if EWG changes its mind, the library side of
things is ready to go. And obviously everything I just said could change
next meeting.

Niall
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|

Re: [review][LEAF] Review of LEAF

Boost - Users mailing list

On Mon, 1 Jun 2020 at 09:19, Niall Douglas <[hidden email]> wrote:

Thanks for the supplemental information.

degski
--
@systemdeg
"We value your privacy, click here!" Sod off! - degski

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users