Subject: Re: [boost] Noexcept
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-06-14 20:35:01
On 6/14/2017 3:42 PM, Ion Gaztañaga via Boost 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.
Please explain what this is supposed to mean, because it does not mean
anything to me.
>
> 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