Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-06-15 19:17:13

On 15/06/2017 0:54, Emil Dotchevski via Boost wrote:
>> If the exceptional path is not explicit, it is very easy to incorrectly
>> handle it or just to ignore that path. Just like strong types are safer,
>> explicit paths are safer.
> 
> ...and when it is not, you can use explicit path:
> 
> try { stuff }
> catch(...) {
>    cleanup();
>    throw;
> }

Then there is no advantage of using exceptions, so better stick to 
errors which at least limit the types that must be handled, which 
usually reduces compiler-generated code (obviously the diagnostic is 
poorer, as you can't compare an int error return with a full class).

> If you didn't use exceptions, the above would look like this:
> 
> if( stuff_failed ) {
>    cleanup();
>    return E_STUFF_FAILED;
> }

If all you need is "stuff_failed" then exceptions are better because you 
just want to cleanup and return. Exceptions do this automatically. 
Problems arise when you wan to handle all possible errors, do different 
things with each of them. And just make sure you correctly handle all 
errors.

I find myself writing exception safe code, but rarely using them. And I 
rarely find programmers that properly understand how to use exceptions, 
whereas everybody understands a return type.

It's rare that we are saying that being strong typed is good, that 
abstract base classes are great to enforce the possible polymorphic 
operations at runtime, that concepts must be brought to language to 
explicitly reduce the types that must be handled by an operation (at 
compile time), but on the other hand we permit any type (even unknown 
ones by the caller) to be returned by exceptions. Looks like a 
contradiction to me, as exceptions to be thrown by an operation look 
like a contract to me.

I don't say errors are superior, I just say that exceptions have not 
succeeded. The STL has succeeded, templates have succeeded, move 
semantics have succeeded, lambdas has succeeded... exceptions are still 
controversial. Now I read that we should use errors for things that are 
not "exceptional". If "exceptional" means to just propagate the error so 
that main catches it a prints to a log, then "std::terminate" can handle 
that more efficiently. ¿What should be done with "truly exceptional" errors?

std::filesystem needs to offer a dual interface for errors and 
exceptions. There is something missing here. And I don't have the answer.

Ion