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@gmail.com> 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