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

From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2020-06-07 20:19:35

On Sun, Jun 7, 2020 at 12:19 PM Joaquín M López Muñoz <
joaquinlopezmunoz_at_[hidden]> wrote:
> 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.

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

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