[review][LEAF] Review of LEAF
On Fri, May 22, 2020 at 2:37 AM Michael Caisse via Boost <boost@lists.boost.org> 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
On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users < boost-users@lists.boost.org> 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.
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 <boost-users@lists.boost.org <mailto:boost-users@lists.boost.org>> 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
On Sat, 30 May 2020 at 18:44, Emil Dotchevski via Boost-users < boost-users@lists.boost.org> wrote:
On Sat, May 30, 2020 at 4:28 PM Sorin Fetche via Boost-users < boost-users@lists.boost.org> 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 Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- @systemdeg https://www.instapaper.com <http://instapaper.com> "We value your privacy, click here!" Sod off! - degski
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
On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users < boost-users@lists.boost.org> 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. The kind of code I write (the application areas) almost always demands logical correctness and other than the mythical OOM, no exceptions can occur (bar a bit of IO, which would live somewhere separately), so I have no need for any of these libraries, Most of my testing is fuzzing, let the computer search for bugs, not me or the user. Here I obviously actively use exceptions to figure out what happened if something does happen, it's easier than logging and builtin. degski -- @systemdeg https://www.instapaper.com <http://instapaper.com> "We value your privacy, click here!" Sod off! - degski
On 01/06/2020 14:48, degski wrote:
On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users <boost-users@lists.boost.org <mailto:boost-users@lists.boost.org>> 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
On Mon, 1 Jun 2020 at 09:19, Niall Douglas <s_sourceforge@nedprod.com> wrote: Thanks for the supplemental information. degski -- @systemdeg https://www.instapaper.com <http://instapaper.com> "We value your privacy, click here!" Sod off! - degski
participants (4)
-
degski -
Emil Dotchevski -
Niall Douglas -
Sorin Fetche