Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-06-14 21:42:13

On 14/06/2017 21:52, Richard Hodges wrote:
> Exception return paths are not infinite. There are a finite number of
> places in code that an exception can be thrown.

Correct. There are infinite possible types that can be thrown.

> The exception path is one path, the non-exception path is another.
> That’s two in total. Exactly equivalent to an outcome<>.

Right.

> It is a fallacy to say that there are an indeterminate number of
> paths.

I stand corrected. Let me rephrase my assertion: with errors you have a 
limited range of values in a single type that you must handle. With 
exceptions you have an indeterminate number of types, each of them with 
a limited number of states/values. If you want to "handle" all of them, 
you need an undetermined number of catch statements because the type can 
be absolutely unknown to the handler. The programmer that must handle 
the exception can't be prepared for that. Instead, the programmer can be 
prepared to handle a limited number of exceptions that a function might 
throw, but that implies translating lower layer exception types to a 
finite number of exception types, which is very similar to handling and 
translating error codes. Exceptions shine when the programmer refuses to 
handle errors.

> If developers do not understand RAII, then an afternoon of training
> can solve that.
> 
> RAII is the foundation of correct c++. It is the fundamental
> guarantee of deterministic object state. A program without RAII is
> not worthy of consideration. The author may as well have used C.

You can't correctly write exception safe code only with simple RAII. 
There are chained operations that must be undone on the presence of an 
error. 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. Exceptions imply weakly 
defined control paths. And that's a real problem for safety. Exceptions 
are great when you don't want to handle the exception, so the compiler 
automatically propagates control to the upper layers.

> Perhaps there is an argument that says that RAII adds overhead to a
> program’s footprint. If things are that tight, fair enough.
> 
> Otherwise there is no excuse to avoid exceptions. I’ve never seen a
> convincing argument.
> 
> The fact that people are taking time to re-implement exception
> functionality in outcome<> et al demonstrate the necessity and
> correctness of exceptions.

If people reimplement exceptions, it's because many are not happy with
them, even decades after exceptions were added to C++. Nobody rewrites 
"while" with "goto"s.

> I have yet to see an answer to my initial question - an example of
> code in which compiling without exceptions enabled and checking
> return types instead, will add any performance benefit to the
> non-exceptional case at all.
with table-based implementations, I don't think there is any.

Ion