Re: [boost] [outcome] High level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-05-31 17:05:45

On Wed, May 31, 2017 at 6:45 AM, Niall Douglas via Boost <
boost_at_[hidden]> 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_at_[hidden]>:
> >>
> >> 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.