Does adding `noexcept(false)` benefit the code in any way?

Question

Recently in my code I have been explicitly writing noexcept(false) on functions that I know do throw exceptions, mainly for people reading the code. However, I am wondering if this affects the behavior of my code or the way the compiler interprets it. Does it make any difference?

Note: I am aware that destructors are implicitly noexcept and that you have to specify noexcept(false) to change that, I am wondering about other functions.

Answer 1

Having no exception-specifier and explicitly stating noexcept(false) are equivalent, see §15.4/12:

A function with no exception-specification or with an exception-specification of the form noexcept(constant-expression) where the constant-expression yields false allows all exceptions.

So the compiler should not distinguish between them when considering exceptions.

---

More importantly, there's no need for you to be tacking on noexcept(false) to your functions. As a C++ developer, you should assume every function throws by default (which is why the standard takes this stance), so you're adding no new information by writing it out; it's a waste of time for everyone.

Rather, do mark the special case where a function definitely does not throw with noexcept, and do mark the cases where a function may throw depending on some condition with noexcept(condition).

If your function is purposefully the source of some exception E, write that in your documentation.

Answer 2

The one case I can think of is on a destructor. I know you should never throw in a destructor. But in some cases you are stuck with code that does this and have no work around.

Since c++ automagically adds noexcept to destructors, this is the only way to undo it and prevent app terminate when the code throws.

https://github.com/chriskohlhoff/asio/issues/1216

from: https://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/

The compiler will still invisibly add specification noexcept to your destructor. And this means that the moment your destructor throws an exception, std::terminate will be called, even if there was no double-exception situation. If you are really determined to allow your destructors to throw, you will have to specify this explicitly; you have three options:

1. Explicitly specify your destructor as noexcept(false),
2. Inherit your class from another one that already specifies its destructor as noexcept(false).
3. Put a non-static data member in your class that already specifies its destructor as noexcept(false).

Answer 3

In his book More Exceptional C++, Herb Sutter has the following snippet (pp. 130):

The right answer to the Example 19-1 is much simpler:

// Example 19-4: The right solution
//
T::~T() /* throw() */
{
 // ... code that won't throw ...
}

Example 19-4 demonstrates how to make a design decision instead of waffling.

Note that the throw() throws-nothing exception specification is only a comment. That's the style I've chosen to follow, in part because it turns out that exception specifications confer a lot less benefit than they're worth. Whether or not you decide to actually write the specification is a matter of taste.

(emphasis mine)

So, I feel I must point out that one of the leading experts in C++ exception-safe code seems to be against the whole concept of adding exception specifications for the compiler to use (but still leaving it in the code for the programmers to understand).

Just thought it may be interesting info...