Re: [boost] Noexcept

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

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