2017-05-31 22:42 GMT+02:00 Niall Douglas via Boost
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;