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

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2020-06-07 21:18:27

El 07/06/2020 a las 22:19, Emil Dotchevski via Boost escribió:
> On Sun, Jun 7, 2020 at 12:19 PM Joaquín M López Muñoz <
> joaquinlopezmunoz_at_[hidden]> wrote:
>> Emil Dotchevski via Boost escribió
>>
>> > 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 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.

Still don't get it. Can you provide an example where throwing an exception
within try_handle_* results in resolution by a non-catch_ handler?

>
>> So, what's the point of allowing non-catch_ handlers in try_catch?
> 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.
>

Can you provide an example where a non-catch_ handler is effectively 
used in a
try_catch statement?

>> Also, seems like
>> try_handle_some provides a superset of the functionality offered by 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.
>>

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?

Joaquín M López Muñoz