On Wed, Jun 14, 2017 at 2:42 PM, Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
There are chained operations that must be undone on the presence of an error.
That is the strong guarantee. Basic guarantee is usually trivial...
If the exceptional path is not explicit, it is very easy to incorrectly handle it or just to ignore that path. Just like strong types are safer, explicit paths are safer.
...and when it is not, you can use explicit path: try { stuff } catch(...) { cleanup(); throw; } If you didn't use exceptions, the above would look like this: if( stuff_failed ) { cleanup(); return E_STUFF_FAILED; } which is semantically identical except for the difficulty of having to communicate failures through the return value. Both C++ exception handling and Noexcept provide a more elegant path for error objects.
Exceptions imply weakly defined control paths. And that's a real problem for safety.
What safety do you have in mind?
Exceptions are great when you don't want to handle the exception, so the compiler automatically propagates control to the upper layers.
Which is 99% of the functions in your code, which means that if you use RAII, there is little chance of these functions to have subtle bugs which, being in the error-handling code, are _very_ difficult to detect. And if you use exceptions, you get the equivalent of "if( stuff_failed ) return E_STUFF_FAILED" automatically. If people reimplement exceptions, it's because many are not happy with
them, even decades after exceptions were added to C++. Nobody rewrites "while" with "goto"s.
That many people aren't happy with something doesn't indicate a problem. The horse, the water, etc. :) All that said, there are valid reasons why you may not want to use exception handling, but they have more to do with the team you have rather than problems inherent in the exception handling semantics or its abstraction penalty.