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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 20:42:17

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/