throw in function name

Hello

I've came across some code which looks like:

Code:

---

class someclass {
public:
  virtual void somefunction() throw;
};

---

Whats the meaning of that throw after the function's arguments? When should I use it?

Thanks for help!

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".

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

I wrote it wrong:

Its actually:

Code:

---

virtual void somefunction() throw();

---

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.

Quote:

---

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.

Quote:

---

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";
    }
}

---

But the compiler doesn't complain if your function can throw an exception that isn't specified, and the only option in that case is to terminate your program, which is a pretty bad thing.
Take this example:

Code:

---

void OldFunc()  // NOTE:  no throws declaration, so it might throw anything.
{
  ...
}

void NewFunc() throw std::exception
{
  OldFunc();
  ...
}

---

Now if OldFunc() only throws std::exception then everything is fine, but the minute someone makes a change to OldFunc() and throws something else, your program will now terminate if that exception happens, even if you have a catch block further up the call chain that does handle that new exception.

Boost says exception specifications are bad, as do the authors of many C++ books.

In a language like Java where exception specifications were built into the language right from the beginning, they do make sense, but since they are optional in C++ and the compiler is unable to detect cases where an unspecified exception may be thrown, it's just another one of those good ideas that didn't quite work in C++.

Quote:

---

Originally Posted by cpjust

Now if OldFunc() only throws std::exception then everything is fine, but the minute someone makes a change to OldFunc() and throws something else, your program will now terminate if that exception happens, even if you have a catch block further up the call chain that does handle that new exception.

---

So change the specification and recompile, right? Then the code that uses the old specification will give a compile error, right?

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.

Quote:

---

Originally Posted by anon

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.

---

Destructors and delete operators must never throw also.