Thread: throw in function name

It looks like it might be placeholder for the function until the code is written. Sort of a "I need to write this piece of code, and in case I used the function before it's written, the throw will remind me to write it".

Originally Posted by medievalelks

It's an exception specification that indicates what exceptions a function might throw (in this case, none).

Thanks for the correction.

BTW, it's a good idea to avoid using exception specifications in your own code since they have no real benefit and require all code calling that function to use exception specifications.

Are you saying that exception scecifications are a virus in the sense const and unsigned/signed are (because it doesn't seem that way)?

As I understand it, if an exception is thrown nevertheless it is not a compile time error, but at runtime instead of propagating the exception, unexpected() is called which calls an unexpected handler which is not allowed to return but has to terminate the program one way or another. This way the promise made in the exception specification is enforced at runtime.

If I'm not mistaken they are useless in case of template code, because you can't take any responsibility for what any particular template argument type might throw.

You may try different combinations of commenting/uncommenting the two throw's in foo.

Code:

#include <exception>

void foo() throw()
{
    throw 1;
}

void bar()
{
    foo();
}

void oh_my_god() throw()
{
    std::cout << "Program was terminated by unexpected exception\n";
    exit(1);
}

int main()
{
    std::set_unexpected(oh_my_god);
    try {
        bar();
        std::cout << "Everything's fine\n";
    }
    catch (...) {
        std::cout << "Exception happened\n";
    }
}

The idea was probably to provide "comments" whose correctness is enforced at run-time. But comments tend to go out of sync with the code, and it is often that the code is correct and the comment is wrong, so this mechanism is quite inconvenient indeed. (But to write robust code you often need to know what type of exceptions you can expect.)

But anyway, your example is now the other way round. It's not that if a function has a throw specification, functions calling that (functions up the chain) have to have one too. Instead in your example, if some function down the chain doesn't make any promises, functions calling that one can't make any promises either.

There are, however, certain operations that should never throw (e.g the exception class itself, swap function), so a no-throw specification might be in order.

Edit: well, if the exception specification of something down the chain changes, every function up the chain that calls this function and uses exception specification needs to be changed. It might be an enormous work to track down, change and recompile all of them.
On the other hand, if a low-level function is modified to throw new types of exceptions, lots of user code would have to be changed anyway.