On Wed, May 31, 2017 at 6:45 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
On 31/05/2017 14:25, Andrzej Krzemienski via Boost wrote:
2017-05-31 15:17 GMT+02:00 Niall Douglas via Boost < boost@lists.boost.org>:
If you need a motivating example, imagine a user accumulates result<T>'s from other code it calls into outcome<T>'s, and then does .exception() on the outcome<T>'s.
Yes, I can understand why one wants to treat error_code and exception_ptr uniformly. But recognizing an error_code in `exception()` and not recognizing an exception_ptr in `error()` looks quite arbitrary to me: not guided ba an intuitive mental model.
Not at all.
Errors are not exceptional. They are expected failure.
Exceptions are exceptional. They are **un**expected failure.
By which definition is that true? When I call a function which may throw, that is not unexpected at all. The calling code is specifically designed to deal with that possibility. I see the difference between a C function returning ERROR_OPEN_FAILED and a C++ function throwing open_failed_errror() as purely mechanical. Proceeding to read the file when ERROR_OPEN_FAILED was returned is an error, and 99 times out of 100 you need an if to prevent control from reaching that code. In the open_failed_error() case the compiler writes the if for you, that's about it the only difference.