On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost < boost@lists.boost.org> 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.

On Fri, May 29, 2020 at 1:10 AM Richard Hodges via Boost < boost@lists.boost.org> wrote:

Thank you for your response.

On Fri, 22 May 2020 at 21:30, Emil Dotchevski via Boost < boost@lists.boost.org> wrote:

...

On Fri, May 22, 2020 at 3:51 AM Richard Hodges via Boost < boost@lists.boost.org> 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).

and - Does LEAF incur any memory or runtime performance overhead in the non-error case?

I think I understand now. The construct of try_handle_all(lambdas...) is building an "error context" into which later leaf-enabled functions down the call stack can emplace error info. The address of this context is maintained by logically a separate "context stack" which lives in the call stack. To be strictly correct, would it be fair to say that there is memory allocation, it just happens to be on the call stack and therefore requires very little book-keeping overhead and no mutual exclusion?

...

I do not have open source production code to share, but I could possibly show you some code personally.

This would be helpful.

At the moment, I get the impression that this is a very elegant solution to a problem I don't have. I want to be even handed during the review. It would be helpful to see some code from a domain where this solution solves a very real problem, or have a domain described where LEAF clearly solves a real problem. For that "Oh Wow!" moment that you have presumably

Yes. I meant no dynamic allocation. The minimal bookkeeping is logically similar to a tuple<optional<E>...>. personally

experienced.

If I'm not mistaken you said you use Boost Exception. That indicates you do have the problem that you said LEAF solves more elegantly (and more efficiently) than Boost Exception. To be more precise, LEAF is designed to help you communicate _all_ data needed to handle a given failure, from any scope it is available, to the correct error handler. It can do this even through layers of uncooperative APIs.

On Sat, May 30, 2020 at 7:43 AM Bjorn Reese via Boost <boost@lists.boost.org> wrote:

On 2020-05-22 21:30, Emil Dotchevski via Boost wrote:

...

...

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

Can you elaborate on this with regards to runtime performance?

In the successful case, the runtime overhead of C++ try-catch blocks is a jump over the catch block.

By "generally no" I meant that the work is mostly limited to try_catch. In more details, on the happy path:: - At try_catch: a local tuple<slot<E>...> is initialized, where E... is basically the argument types of all the error handlers, with duplicates removed. Each slot<E> zeroes an int, and a TLS pointer for each of E... is set to point the corresponding slot<E>... . When exiting the try_catch, this is undone. - Things like preload cache all their arguments locally, by moving, later to be discarded if no error has occurred.

On Mon, Jun 1, 2020 at 4:36 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:

With exceptions we now have nested_exception, but they both might wish to transport a filename, for example, and these may be different at each level.

Two options: 1) You want to capture the error objects reported by a lower level function, and then later look at them elsewhere. Here is an example on how to do this: With exceptions: https://github.com/zajo/leaf/blob/master/examples/capture_in_exception.cpp?t... . With leaf::result<T>: https://github.com/zajo/leaf/blob/master/examples/capture_in_result.cpp?ts=4 . This is analogous to nested exceptions, the exact context type is erased and the context is transported in an exception or in a leaf::result<T>. 2) A lower level function has failed but you don't want to report this as a new error so to speak, you just want to add more info to the existing failure. Ideally the two functions would use different error types, and in this case it'll just work, just use preload(). Otherwise, it might make sense to wrap the individual types that clash, rather than the whole context. Here is an example: try_catch( [&] { ...something that could throw... }, []( leaf::error_info const & e, leaf::e_file_name const & fn ) { e.error().load( e_wrapped_file_name { fn } ); throw; } ); This handler will execute for any exception that has e_file_name. We just wrap it in another type and rethrow. (The reason why this is needed is that a context can hold no more than one object for each type. In principle this can be changed, in which case you could have two e_file_name stored in the same context, associated with two different error_ids.)

On Mon, Jun 1, 2020 at 6:54 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:

...

This is analogous to nested exceptions, the exact context type is erased and the context is transported in an exception or in a leaf::result<T>.

That appears to be parallel exceptions, not nested exceptions. I don't think these are analogous, given that remote_try_catch appears to be using some kind of magic to figure out which captured context to inspect, but you would instead presumably need to tell it explicitly whether you are looking at the context of the top-level exception or the nested exception.

I see why you say it's not like nested exception. What you refer as magic in remote_try_catch is actually simple: it itself has a local context<>, and the internal machinery detects that the passed result<T> (or the exception) wraps a context in it, and tells the wrapped context, through a virtual function call, to spill its content which is captured in the local context, and from then on everything proceeds as usual. I'll add that the the lowest level API exposed by LEAF works directly with the context<> type. You could: leaf::context<E1, E2, E3> ctx; ctx.activate(); .....; // call functions that report E1, E2, E3 errors, obtain an error_id ctx.deactivate(); .....; // possibly move ctx somewhere else R r = ctx.handle_error<R>(id, <list of error handlers>); I'm showing this because depending on the use case it might be useful; context<> is very similar to tuple<>, and so you could move it about and handle errors later. As I type this, i realize that Bjorn is right that this needs a get<I> interface.

...

2) A lower level function has failed but you don't want to report this as a new error so to speak, you just want to add more info to the existing failure. Ideally the two functions would use different error types, and in this case it'll just work, just use preload().

For a possible use case (I'm sure there are others), imagine a "safe file saver" class that uses backup files. The higher-level error reporting wants to report the filename that the caller was actually trying to save, and yet the underlying internal file API might want to report that the problem actually occurred when saving either the real file or the backup file.

Obviously the low-level function doesn't know that it's dealing with a backup file, so it would just have a generic e_filename.

And the higher-level function will likely want to report its intended filename as an e_filename as well, as that is the one the caller cares about.

But does that mean that it would need to (and is this even possible?) move the underlying low-level filename to a new e_real_filename or similar in order to give e_filename a different value?

Yes, possible. You write a handler that takes leaf::error_info, call its .error() to obtain the error_id of this error, then .load the new value for e_file_name.

This sort of thing seems like a flat error reporting model rather than a nested model, and flat errors tend to lose information. (Not that C++'s mechanisms for nested exceptions are particularly wonderful.)

Indeed. I try to use different types for different things. You're saying that both libs would use leaf::e_file_name, but really they shouldn't, it'd be better if each defines a type within its own namespace. After all, the reason why "flat" error reporting tends to lose information is that there isn't efficient storage to send everything over. With LEAF, there is -- just make sure all error info is properly namespaced.

...

(The reason why this is needed is that a context can hold no more than one object for each type. In principle this can be changed, in which case you could have two e_file_name stored in the same context, associated with two different error_ids.)

Presumably this would not be possible without either reintroducing memory allocation or pre-declaring the max number of possible nested errors either per-context or globally.

Yes, per context. But really I don't want to do that, it's rather inelegant.

On 6/3/20 07:23, Bjorn Reese via Boost wrote:

On 2020-06-02 04:37, Emil Dotchevski via Boost wrote:

...

I'll add that the the lowest level API exposed by LEAF works directly with the context<> type. You could:

leaf::context<E1, E2, E3> ctx; ctx.activate(); .....; // call functions that report E1, E2, E3 errors, obtain an error_id ctx.deactivate(); .....; // possibly move ctx somewhere else R r = ctx.handle_error<R>(id, <list of error handlers>);

I'm showing this because depending on the use case it might be useful; context<> is very similar to tuple<>, and so you could move it about and handle errors later. As I type this, i realize that Bjorn is right that this needs a get<I> interface.

I somehow missed the context::handle_error() function during the review. This addresses my main concern about avoiding wrapping the "TryBlock".

Review manager: This changes my conditional accept into an unconditional accept.

Thank you for the clarification Bjorn. -- Michael Caisse Ciere Consulting ciere.com

On Tue, Jun 2, 2020 at 2:32 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:

...

By "generally no" I meant that the work is mostly limited to try_catch. <deleted details> Doesn't this state the opposite of "generally, no" or am I missing anything?

The happy path includes everything that happens when there is no exception thrown, not only what happens at the try...catch, that's what I meant.

So I think the request for a comparison of the happy cases for LEAF and exceptions is justified.

A benchmark can be added, sure. Here's the initialization code generated by leaf::try_catch that deals with a context that has a struct e_info { int value; }: mov dword ptr [rsp + 8], 0 mov rax, qword ptr fs:[0] lea rax, [rax + boost::leaf::leaf_detail::slot<e_info>*& boost::leaf::leaf_detail::tl_slot_ptr<e_info>()::s@TPOFF] mov qword ptr [rsp + 16], rax mov rax, qword ptr fs:[boost::leaf::leaf_detail::slot<e_info>*& boost::leaf::leaf_detail::tl_slot_ptr<e_info>()::s@TPOFF] mov qword ptr [rsp + 24], rax lea rax, [rsp + 8] mov qword ptr fs:[boost::leaf::leaf_detail::slot<e_info>*& boost::leaf::leaf_detail::tl_slot_ptr<e_info>()::s@TPOFF], rax This initialization does not depend on the type of ::value. The long gnarly names are TLS offset constants.

On Sun, May 24, 2020 at 1:14 AM Rainer Deyke via Boost < boost@lists.boost.org> 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).

On Fri, May 29, 2020 at 1:26 AM Alexander Grund via Boost < boost@lists.boost.org> wrote:

Maybe improve on `remote_handle_all` in 2 ways: Create the lambda taking `leaf::error_info const&` in that function to remove the boilerplate at the user call site. Given that rename it to e.g. `create_remote_handler` or so. I find the current interface confusing and the documentation calls it "unintuitive", so I guess this should be improved on before release. Given that: It seems `remote_try_handle_all` can be folded into the regular `try_handle_all`. So `try_handle_all` takes a list of handlers where one could be the aggregated handler defined by `create_remote_handler` (then maybe `create_aggregate_handler`?)

I've explored folding it all into try_handle_all, but the implementation gets really messy. Perhaps it can be done. Consider that in this case the loop that matches the lambdas based on what error objects are available at runtime now has to be recursive. Maybe it can be done elegantly, but I tried and gave up.

I'm interested in knowing how `try_handle_all` implements "if the user fails to supply at least one handler that will match any error, the result is a compile error". If arbitrary functions can be called throwing any error type, how could that work? Is it again required to use a catch-all clause?

Yes, you must supply a handler that matches any error. If you don't want to do that, use try_handle_some. The benefit of _all is that it unwraps the result for you: where try_handle_some returns a result<T>, try_handle_all returns T. It also guarantees at compile time that the user has provided a suitable handler for all errors.

...

- What is your evaluation of the documentation? Good overall, but the details are to detailed for an introduction and to coarse for understanding it.

Thanks for this feedback.

- "Using Exception Handling": virtual inheritance is mentioned but the reasoning is not clear to me. I have never used or seen it used in that context and always strive to avoid it due to the issues with handling such an object (starting at writing ctors)

This is a somewhat-known problem with exceptions. If you have: struct A { }; struct B1: A { }; struct B2: A { }; struct C: B1, B2 { } Now a catch(A &) won't intercept a C because the cast is ambiguous. Using virtual inheritance eliminates this problem and allows A to be safely used as a base of anything that should be classified as A.

- "Accumulation": shows how to call leaf::accumulate but I don't see what it use is. "Many different files" are mentioned but the operation only takes a single file. And based on everything before a single error stops execution (like exceptions)

Normally you give LEAF an object of type T and it stores it away for you. If you later give it another value of type T, it'll just overwrite the old one. With accumulate, you get a mutable reference to the stored value (and it requires T to have a default constructor).

- "error_id": It is unclear to me what it's use is. Especially as something unique in the program in the context of threads means some kind of synchronization which will be paid for even if unused.

See https://zajo.github.io/leaf/#tutorial-model

- "defer": I'd like to know when the lambda is not called. The documentation says it is called in the dtor, but later: "function passed to defer, if invoked,"

The logic is the same as for preload, which takes your value, and will later communicate it if an error has occurred, while defer takes your lambda and will later call it to get a value to communicate, if an error has occurred.

I'd also like to see a comparison with exceptions especially in cases where the usage of result<T> inhibits (N)RVO (even more for C++17 and up). This is my main critic point about result<T> type of error handling as that variant type creates less efficient code for the happy path.

Yes, though leaf::result<T>, in case of an error, only transports a single int, the error_id, which allows for efficient implementation. That said, you can use pretty much any result type with LEAF, it does not have to be leaf::result<T>. Thanks!

Alexander Grund wrote:

With an API like `result<Foo> do() noexcept` instead of `Foo do()` you won't get (N)RVO when you return a `Foo` (in the happy case) as the standard only allows it when the types are exactly the same.

This doesn't matter much nowadays. E.g. in https://godbolt.org/z/zC-Cah if you remove x.f(), x goes away.

Alexander Grund wrote:

Not sure if that really proves the point. I think you need to compare a result<X> function to a function returning X directly. Like so: https://godbolt.org/z/JFmn_j

And for that there is a difference: There are 4 main memory accesses in the result<X> function and none in the "regular" one.

That's not because of NRVO, it's because X fits in registers and result<X> doesn't.

On Fri, May 29, 2020 at 6:20 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:

...

- What is your evaluation of the design? I like it.

I didn't have enough information to form an opinion of LEAF, but Niall's endorsement definitely sets off warning bells and red flags. Regards

- What is your evaluation of the design? It's very clean. While I'm not a big fan of the macros, I do like how it's somewhat reminiscent of vanilla C++ exceptions. Some minor nit-picking here: trailing underscores following names that are public doesn't look particularly right; makes it look like you're using you aren't supposed to :) - What is your evaluation of the documentation? The documentation is great -- in terms of styles it's probably the best I've seen for a C++ library. The examples are great and they do a good job of communicating how the library works by providing realistic scenarios. It's quite well done. - What is your evaluation of the potential usefulness of the library? While this is not something I have found a need for, the motivation for this libraries existence is weill founded and I can see use cases for it. - Did you try to use the library? With which compiler(s)? Did you have any problems? I did not. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent about an hour going through the documentation. - Are you knowledgeable about the problem domain? Not really :) In terms of acceptance, I'm neutral on that front as this is not something I am well versed in.

Krystian Stasiowski wrote:

Some minor nit-picking here: trailing underscores following names that are public doesn't look particularly right; makes it look like you're using you aren't supposed to :)

That's standard Boost/MPL convention for identifiers that would otherwise be keywords, such as int_ or if_.

This is my review of LEAF as a long-time user and proponent of Boost:

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).

ACCEPT

- What is your evaluation of the design?

It's similar to many Boost libraries before it in that it's incredibly rich, nuanced and can give you the most cryptic and hard-to-decipher compiler errors. However, the more I used it and become accustomed to its idioms, the more I found myself enjoying it. `preload` is the most simple and elegant abstraction I've seen for incrementally adding information to an error context as it travels back up the callstack. I've seen similar patterns be attempted in Go and LEAF far and away has the most powerful and type-safe approach. `preload` should, however, have a [[nodiscard]] attribute attached to it. `try_handle_all` is a nicer alternative to exception handling though it can be difficult to tell if an overload is going to be called when trying to match up against errors. I'm assuming this is simply because of my inexperience with the library and is something that will be alleviated with time. The library also works very well with normal exception based code. leaf::catch_ and leaf::exception_to_result are useful abstractions that help the user integrate LEAF piece-by-piece into the codebase which is important when looking at updating existing code. Because users can manually control the error context (including storing it and using RAII-like wrappers to activate it), it's usable in Asio which is a hard requirement for me. Overall, the design of the library is quite powerful and is relatively simple for how much it does.

- What is your evaluation of the implementation?

As a user, the only thing that matters to me is: is it better than I could've done myself? And the answer to that question is a resounding "yes!" Otherwise, the implementation details are best left evaluated by a fellow library author which I am not aiming to be in this instance.

- What is your evaluation of the documentation?

Parts seemed out of line with what was in the examples (I'm thinking of exception_to_result) but overall, the documentation has good styling and goes into quite a bit of depth. The examples in the source repo are quite good as well. As a user, I found myself able to reference things and get a working example relatively quickly that show-cased the power of LEAF.

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

Incredibly useful. When writing user-facing applications, it's important that one gathers up appropriate data to craft a useful error message to display. It's also incredibly useful because of the type-safe matching in try_handle_all. Error codes are not sufficient many times and LEAF minimizes the amount of boilerplate one would have to use to update existing code.

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

I did. It installed perfectly with CMake and was able to be find_package()'d easily. I used gcc 10.0.1 in WSL.

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

I dedicated around 2 to 3 hours playing around with it in addition to spending about an hour last week reading the docs. Even though I'm not fully adept with using the library, I see its potential. Many Boost libs require time to learn and digest and they're fantastic (I'm thinking of Asio, Beast, Spirit) so I'm not holding any stumbles I encountered against it.

- Are you knowledgeable about the problem domain?

If the problem is error handling, I'm decently well-versed. I've written many user-facing applications and have wound up reimplementing what LEAF does a couple of times. Some closing thoughts... LEAF doesn't have to be perfect to be accepted. I think as of now, it's documented and completed enough that it can be picked up and used but more importantly, I think its core goal is worthwhile enough that it should be iterated on and refined by many users trying it out and providing their feedback. I've seen this pattern be re-implemented in Go and in many codebases I've worked on professionally. LEAF far and away has the best implementation I've personally seen and for that reason, I think it should be wholeheartedly accepted into Boost. - Christian

El 06/06/2020 a las 22:53, Emil Dotchevski via Boost escribió:

On Sat, Jun 6, 2020 at 4:21 AM Joaquin M López Muñoz via Boost < boost@lists.boost.org> wrote:

...

[...] * I feel like is_result_type should be converted into a traits class (like allocator_traits) with value() and error() static functions so as to make it easier to adapt external error types into the framework. Possibly. I prefer to not add complexity that is not strictly needed.

I'd say this doesn't add complexity for the user, but on the contrary makes it easier to detect and adapt result types. I'm thinking about something like this:     template<typename T,typename=void>     struct result_type_traits;     template<typename T>     struct result_type_traits<       T,       boost::mp11::mp_void<        decltype(static_cast<bool>(std::declval<T>())),        decltype(std::declval<T>().value()),        decltype(std::declval<T>().error())       >     >     {       static bool has_error(T& x){return static_cast<bool>(x);}       static decltype(std::declval<T>().value()) value(T& x){return x.value();}       static decltype(std::declval<T>().error()) error(T& x){return x.error();}     };     template<typename T,std::size_t=sizeof(T)>     std::true_type  is_complete(T*);     std::false_type is_complete(...);     template<typename T>     using is_result_type=decltype(is_complete(std::declval<result_type_traits<T>*>())); So, if I have a result type that fits the requirements:     struct my_result_type     {       operator bool(){return true;}       int value(){return 0;}       int error(){return 1;}     }; then is_result_type<my_result_type>::value is true automatically and result_type_traits<my_result_type> works out of the box. When I have something that requires adaptation, specializing result_type_traits suffices:     template<>     struct result_type_traits<FILE*>     {       static bool has_error(FILE* p){return p==nullptr;}       static FILE* value(FILE *p){return p;}       static int error(FILE *p){return errno;}     };     // is_result_type<FILE*>::value is automatically true In fact, with this approach is_result_type probably need not be a public type.

...

* Using LEAF requires that called functions be wrapped/refactored so as to return a leaf::result<T> value. Not a requirement. In fact one of the main design goals of LEAF is to support transporting error objects of arbitrary types through intermediate uncooperative layers of functions.

Yes, right.

...

Given that users are already expected to use LEAF_AUTO to reduce boilerplate, maybe this macro can be augmented like this:

namespace leaf{ template <typename T> [[nodiscard]] result<T> wrap_result(result<T>&& x){return std::move(x);} template <typename T> [[nodiscard]] result<T> wrap_result(T&& x){return ...;} // figure out what values of T are an error Possible, however I'm exploring what I think is a better option to enable this functionality. It is possible to make LEAF able use non-result<T> types directly, without having to wrap them.

I'd say result_type_traits would enable this, in fact.

...

* Maybe LEAF_AUTO and LEAF_CHECK can be unified into a single, variadic macro. Just a naming observation here.

* Maybe there should be a (BOOST_)LEAF_ASSIGN macro to cover this:

LEAF_AUTO(f, file_open(file_name)); ... // closes f LEAF_ASSIGN(f,file_open(another_file_name)); Possible, but I'd rather not facilitate reusing of local variables.

Not sure I'm explaining myself... Perfectly valid code (the majority, I'd say) assigns values to local variables after the variable has been constructed. LEAF_AUTO hides away error handling on construction, but there is no equivalent for assignment. So the LEAF user would have to write workarounds like:    LEAF_AUTO(f, file_open(file_name));    ... // closes f    LEAF_AUTO(f2,file_open(another_file_name));    f=f2; or worse yet handle error checking explicitly.

...

* Whis is there a need for having separate try_handle_all and try_handle_some? Isn't try_handle_some basically equivalent to try_handle_all with a [](leaf::error_info const & unmatched) handler? Two reasons:

1) try_handle_all ensures at compile time that the user has provided a "catch all" handler. Consider that without this requirement, under maintenance someone may delete it and now the program has a subtle, difficult to detect bug.

2) because try_handle_all knows all errors are handled, it can unwrap the result type and return a value.

I see, thank you. Didn't notice try_handle_all and try_handle_some return types are different, not sure this is a beautiful decision designwise but it's ok, but this is more of a personal opinion I guess.

...

* I may be wrong, but I feel like error-handling and exception are completely separate. Is it not possible to have try_handle_all handle both [](leaf::match<...>) and [](leaf::catch_<...>) handers? The framework could statically determine whether there's a catch handler and then insert its try{try_block()}catch{...} thing only in this case, so as to be exception-agnostic when needed. That is exactly how LEAF works. Use catch_ in any of your handlers, and try_handle_all/some will catch exceptions, otherwise they won't (the third alternative, try_catch, always catches exceptions, and does not use a result type).

I still don't get it. What is the difference between:     int main()     {       return boost::leaf::try_handle_some(         []()->boost::leaf::result<int>{           return 0;         },         [](boost::leaf::match<int,0>){return 0;},         [](boost::leaf::catch_<std::exception>){return 1;},         [](const boost::leaf::error_info&){return 2;}       ).value();     } and     int main()     {       return boost::leaf::try_catch(         []()->boost::leaf::result<int>{           return 0;         },         [](boost::leaf::match<int,0>){return 0;},         [](boost::leaf::catch_<std::exception>){return 1;},         [](const boost::leaf::error_info&){return 2;}       ).value();     } (I've verified both compile ok). Joaquín M López Muñoz

On Sun, Jun 7, 2020 at 2:02 AM Joaquin M López Muñoz < joaquinlopezmunoz@gmail.com> wrote:

I still don't get it. What is the difference between:

int main() { return boost::leaf::try_handle_some( []()->boost::leaf::result<int>{ return 0; }, [](boost::leaf::match<int,0>){return 0;}, [](boost::leaf::catch_<std::exception>){return 1;}, [](const boost::leaf::error_info&){return 2;} ).value(); }

One of your handlers uses catch_<>. This means that your try block will execute inside a try scope, and your handlers will execute in a catch scope. If the try block throws, LEAF will catch the exception and attempt to find a handler. It doesn't have to be a handler that uses catch_<>, the first suitable handler will be called. If your try block returns a failure without throwing, LEAF will attempt to find a handler also. In this case, the handler that uses catch_<> will not be called, because no exception was thrown. If a suitable handler could not be found, the error is propagated by rethrowing the exception or returning the result<int> returned from the try block, as appropriate.

and

int main() { return boost::leaf::try_catch( []()->boost::leaf::result<int>{ return 0; }, [](boost::leaf::match<int,0>){return 0;}, [](boost::leaf::catch_<std::exception>){return 1;}, [](const boost::leaf::error_info&){return 2;} ).value(); }

With try_catch, your try block always executes in a try scope, and your handlers execute in a catch scope, even if none of them use catch_<>. If an exception is thrown, try_catch will try to find a suitable handler. It does not understand the semantics of the result type.

If the try block throws, LEAF will catch the exception and attempt to find a handler. It doesn't have to be a handler that uses catch_<>, the first suitable handler will be called.

How can a non-catch_ handler be suitable when an exception has been

On Sun, Jun 7, 2020 at 12:19 PM Joaquín M López Muñoz < joaquinlopezmunoz@gmail.com> wrote: thrown? This fits the design. Handlers are considered in order (like catch statements are in C++), and the first one LEAF can supply with arguments (based on available info) is called to handle the error. If a handler doesn't take a catch_<> argument, it means it doesn't need the exception object in order to handle the error.

So, what's the point of allowing non-catch_ handlers in try_catch?

Also, seems like try_handle_some provides a superset of the functionality offered by

The exact type of the exception object may be irrelevant, because you have the option to use use all the other object(s) associated with the failure to discriminate between different errors. try_catch, right? In which

situations would a user need try_catch because try_handle_some does not fit the bill?

try_handle_some/all require your try block to return a result<T> of some sort, and using catch_<> with them is just a way to write unified error handling in cases when exceptions are also possible. try_catch has no such requirement.

On Sun, Jun 7, 2020 at 2:19 PM Joaquin M López Muñoz < joaquinlopezmunoz@gmail.com> wrote:

So, if I'm getting this right, the benefit of try_catch vs. try_handle_* is that the returned type need not be a result<T> (or similar) thing. Is this right?

Can you explain the benefits of using try_catch vs. resorting to language-level "real" try and catch blocks?

One benefit is that you can associate arbitrary error objects with exceptions, and dispatch error handling based on their availability. For example, if you use Boost Exception, you could say: try { f(); } catch( read_error const & e ) { if( auto const * fn = boost::get_error_info<file_name>(e) ) ....; // The exception has file_name associated with it else ....; // file_name not available } With LEAF, you would instead say: leaf::try_catch( [] { f(); }, []( leaf::catch_<read_error>, file_name const & fn ) { ....; // The exception has file_name associated with it }, []( leaf::catch_<read_error> ) { ....; file_name not available } ); This is both cleaner as well as easier to read, as the dispatching follows a uniform pattern, rather than custom if-else logic. (Also, Boost Exception allocates memory dynamically, LEAF does not). So, we could select error handlers based on the type of the exception as usual, but we could also do it based on the types of the other available error objects. Therefore, we can ditch exception type hierarchies altogether. Consider this exception type hierarchy: struct read_error: virtual std::exception { }; struct file_error: virtual std::exception { }; struct file_read_error: virtual file_error, virtual read_error { }; What's the point of this? It is to enable us to handle errors like so: try { f(); } catch( file_read_error const & ) { ....; // handle file read errors } catch( read_error const & ) { ....; // handle read errors that are not file errors } LEAF supports a style of error handling where all exceptions thrown are of type std::exception. In that case, instead of the hierarchy above, we could simply define: struct read_error { }; struct file_error { }; Then, to indicate a file read error, we could say: throw leaf::exception(std::exception(), file_error { }, read_error { }); To handle errors: leaf::try_catch( [] { f(); }, []( file_error, read_error ) { ....; // handle file read errors }, []( read_error ) { ....; // handle read errors that are not file errors } ); Note that we don't bother to use catch_<>, because try_catch always catches exceptions, and we've chosen to not dispatch based on the exception type. Is this a good idea? I think that it is. For example, it enables us to use preload() to add further classification after the initial reporting of the error, as it bubbles up the call stack: config read_config(....); { // mark *any* failure that occurs inside read_config as read_config_error: auto load = leaf::preload( read_config_error { } ); .... // Call functions which throw on error } Then: leaf::try_catch( [] { auto c = read_config(); ....; // call more functions which may fail }, []( read_config_error, json_parse_error ) { ....; // handle read_config failures due to a json parse error }, []( read_config_error) { ....; // handle any other read_config fauilure. } );