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: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-01 09:19:41

2017-05-31 22:42 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> On 31/05/2017 18:05, Emil Dotchevski via Boost wrote:
> > On Wed, May 31, 2017 at 6:45 AM, Niall Douglas via Boost <
> >> 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.
>
> That maxim "exceptions are **exceptional**" is a very, very common one
> in C++. You'll find it said all over stackoverflow and many other sources.
>
> > 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.
>
> Both the Filesystem TS and the Networking TS are designed around only
> throwing exceptions in extremely unusual situations.
>
> Most failure is treated as likely, and returned via error_code.
>
> Outcome copies exactly the same model and philosophy. Errors are
> ordinary (handled at the point of occurrence), exceptions are
> exceptional (abort what we are doing). By uplifting an error into an
> exception, one is basically saying "I can't handle this ordinary failure
> here, please abort everything".
>
> If that sounds very similar to the Rust and Swift error handling model,
> that is because it is. Exception throws are for aborting only. Not
> control flow.

I recommend that we drop terms "exceptional" and "expected". And instead
say "error conditions we chose to treat with explicit control flows" and
"error conditions we prefer to treat with implicit control flows".

Regards,
&rzej;