Re: [boost] Noexcept

Subject: Re: [boost] Noexcept
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-14 22:54:28

On Wed, Jun 14, 2017 at 2:42 PM, Ion Gaztañaga via Boost <
boost_at_[hidden]> 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.