Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-06-14 19:52:44

Exception return paths are not infinite. There are a finite number of places in code that an exception 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<>.

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

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.

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.

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.

> On 14 Jun 2017, at 21:42, Ion Gaztañaga via Boost <boost_at_[hidden]> wrote:
> 
> On 13/06/2017 23:44, Richard Hodges via Boost wrote:
>> So why do developers continue to perpetuate the idea that the use of
>> exceptions impacts performance or deterministic timing of code? It does not.
>> It is no slower and no less deterministic than checking a return code or
>> discriminated union. In fact that is exactly what implementations boil down
>> to in compiled code, with the added benefit of being able to signal the
>> failure to create an object in a way that makes it impossible to use the
>> failed object accidentally.
>> As I say, being able to return partial success is useful.
>> Seeking to remove exceptions on performance grounds is a nonsense.
> 
> Maybe. If you are never going to catch an exception, just like many platforms don't need to catch bad_alloc, then log+terminate can be a more efficient approach. But in general, performance benefits disabling exceptions can be attached to specific domains and conditions. Specially today as exception code has improved a lot in compilers. Program size benefits, at least when exceptional situations are handled though abort(), can be measurable, and additionally a polymorphic hierarchy of exceptions types add non-optimizable (by the linker) code and RTTI to your executable.
> 
> It adds non-determinism because there is no upper bound when an exception is thrown.
> 
> In my opinion, at least after writing mission critical software, is that the main problem of exceptions is the non-explicit potentially infinite exit paths (as each thrown type can require a different action when catching) it adds in every function call, worsened with the non-static enforcement of what can be thrown. For critical software every function that could throw should be tested against all possible exceptions thrown by that function or any of its dependencies, and knowing what types dependencies of dependencies throw is an impossible mission.
> 
> A lot of programmers don't understand exception safety guarantees and how to write exception-safe code. It is not simple because it is not explicit.
> 
> IMHO return types, when handled, make error handling uglier, more explicit, maybe slower. You get much more paths and branches, because they really exist in your executable code, and exception handling makes them invisible in your source code, and in consequence, dangerous. Just look at the additional branches gcov shows when you call a function that can possibly throw. It's very hard to test every error and throwable type, whereas an int return type is for most programmers, easier to handle and understand.
> 
> Ion
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost