Can a noexcept function still call a function that throws in C++17?

Question

In P0012R1, \"Make exception specifications be part of the type system\",
I see that noexcept is now becoming a part of the function type.

I

Answer 1

Including the exception specification in the function type is orthogonal to whether a function can call another function with an incompatible exception specification (without handling the exceptions that were not included in its exception specification). The former is about type safety with respect to function pointers (so that you cannot call a throwing function through a function pointer that was known not to throw). Regarding the latter, we can either prohibit it during compilation (as in Java), or treat it as a runtime error (leading to the termination of the program, as is chosen for the C++ current standard).

One may argue by brining the analogy of calling a non-const (non-static) member function from a const (non-static) member function. However the difference is that indirectly modifying an object inside a non-const member function called through a const member function would go undetected (or else would be too costly to detect) and may lead to nasty bugs, that's why it has to be prevented during compilation. Whereas the act of throwing an exception is (should be) an exceptional event and we can afford inserting run-time checks of whether the exception complies with the exception specification and should be let out, or it violates the program logic and should instead terminate the program.

Answer 2

Unfortunately it is valid at compile time.

Although noexcept is used by the compiler to optimize the exception handling code, making the code more performant, it's a shame they didn't push it further to give noexcept a semantic meaning.

Ideally, when you mark a method as noexcept it should also mean that the method is not supposed to let any exceptions bubble up. So if you have a method marked as noexcept but it calls other methods that are not marked as noexcept, that should give you a compile error, unless there is a try/catch block surrounding anything that can throw.

Simply calling std::terminate is a very poor language design choice, because it doesn't put any responsibility at the hands of whoever writes the noexcept method. On the contrary, it harms software reuse by making it impossible even to the consumer to work the problem around.

For example, say that I am a bad library developer and I wrote the following code:

Header file Foo.h that ships with my library:

class Foo
{
public:
    void DoSomething() noexcept;
};

You are happy consumer of FooLib writing a Bar application:

Bar.cpp

#include "Foo.h"

int main()
{
    Foo foo;

    try
    {
        foo.DoSomething();
    }
    catch (...)
    {
        std::cout << "Yay!" << std::endl;
    }

    return 0;
}

That code compiles fine and runs fine until you have Foo throwing an exception... And it doesn't make any difference if you enclose the call to foo.DoSomething() with a try/catch block. The code will simply abort.

If you don't have the code of Foo, you can't fix it. The only solution in this case is to throw away Foo library and write your own.

The contents of Foo.cpp can be something like this:

static void PotentiallyThrowException()
{
    throw 0;
}

void Foo::DoSomething() noexcept
{
    PotentiallyThrowException();
}

Note that it's up to the implementer of Foo::DoSomething() to wrap their own calls into try/catch. But due to the same issue, if they are calling other methods that are marked as noexcept and those developers didn't do the same, now it's Foo::DoSomething() that is hosed. And so on, and so forth.

We can safely say that from the semantic point of view noexcept is not only useless, but it's also harmful.

Answer 3

According to cppreference:

Note that a noexcept specification on a function is not a compile-time check; it is merely a method for a programmer to inform the compiler whether or not a function should throw exceptions.

So the syntax of your code is valid, but std::terminate will be called when executed.

Answer 4

noexcept(true) functions can call noexcept(false) functions. There will be a runtime error if an exception is thrown. The canonical example of why this is allowed is:

double hypotenuse(double opposite, double adjacent) noexcept(true)
{
    return std::sqrt(opposite*opposite + adjacent*adjacent);
}

std::sqrt will throw domain_error if its argument is negative, but clearly that will never happen here.

(In an ideal world, it would be forbidden by default with an exception_cast to allow it where required. The result could either be UB if an exception is thrown, or std::terminate).