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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk