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