Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-14 21:01:57
On Wed, Jun 14, 2017 at 12:42 PM, Ion GaztaÃ±aga via Boost <
> 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.
When an error occurs (assuming you can't just bail out), it must get passed
up the call stack, together with relevant data that is captured at the time
it's detected, but also present in functions up the call stack, all the way
to a function that can actually deal with the problem.
If you don't use exceptions, then you're writing a lot of if( !success )
return error, which is prone to errors.
As well, in environments where error handling doesn't use exceptions, the
code tends to not always use RAII, so in addition to returning errors you
need to manually release resources, which is also prone to errors (say
hello to leaks).
Semantically, however, exception handling only 1) writes the ifs for you,
and 2) forces you to use RAII and to write exception-safe code (which is a
good idea anyway.)
With or without exceptions, the error handling paths as well as the work
that must be done in case of errors (freeing resources, etc.) is identical.
The supposed "unpredictability" of exceptions is not semantic but
syntactic. Depending on the compiler, and depending on whether a function
got inlined or not (even functions that are exception-neutral, e.g. neither
throw nor catch exceptions), there might be overhead which sometimes may be
significant, not to mention I have never seen a compiler that optimizes out
But even this is probably just theoretical. I've been asking for hard data
that shows that in a given use case exception handling adds too much
overhead. I keep hearing that such cases exist (and they probably do) but
I'm yet to see a single one.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk