On Sun, Jun 7, 2020 at 12:19 PM Joaquín M López Muñoz < joaquinlopezmunoz@gmail.com> 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.