Re: [boost] Noexcept

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