Question

i am reading this page http://www.cplusplus.com/doc/tutorial/exceptions.html it says if i write function() throw(); no exceptions can be thrown in that function. I tried in msvc 2005 writing throw(), throw(int), throw() and nothing at all. each had the exact same results. Nothing. I threw int, char*, another type and it was all caught the same way. It looks like throw doesnt affect it at all. What does function() throw() actually do?

Was it helpful?

Solution

See this article for details on C++ exception specifications and Microsoft's implementation:

Microsoft Visual C++ 7.1 ignores exception specifications unless they are empty. Empty exception specifications are equivalent to __declspec(nothrow), and they can help the compiler to reduce code size.

[...] If it sees an empty exception specification, it will assume you know what you are doing and optimize away the mechanics for dealing with exceptions. If your function throws anyway - well, shame on you. Use this feature only if you are 100% positive your function does not throw and never will.

OTHER TIPS

What you're finding is that that version of VC++ didn't enforce specification exceptions. I believe that was documented as a variance from the standard.

However, exception specifications are usually not a good idea. If a program violates them in a standards-conforming implementation (which the VC++ from VS 2005 was not in this case), the system is supposed to catch it. This means that the specification is not a compiler optimization hint, but rather forces the compiler to go to extra lengths, and sometimes produce suboptimal code.

See the Boost rationale for reasons why the highly regarded Boost project does not use exception specifications. This is Boost, which is something of the poster child for doing weird and useful things with advanced parts of the language.

Quoting from A Pragmatic Look at Exception Specifications:

(Mis)understandings

The second issue has to do with knowing what you’re getting. As many notable persons, including the authors of the Boost exception specification rationale, have put it, programmers tend to use exception specifications as though they behaved the way the programmer would like, instead of the way they actually do behave.

Here’s what many people think that exception specifications do:

  • Guarantee that functions will only throw listed exceptions (possibly none).

  • Enable compiler optimizations based on the knowledge that only listed exceptions (possibly none) will be thrown.

The above expectations are, again, deceptively close to being correct.

See the link for the full details.

Throwing an exception is not enough, you need a try {} catch() block to catch exceptions. If you don't catch exceptions, std::terminate() is called and your program exits abruptly. Take some time out and have go at this.

throw specifications are designed for two purposes:

  1. To serve as a contract between interface implemented and interface user - you state which exceptions can be throwned from your method, some people consider it part of an interface. (contract) Ala checked exceptions in Java.

  2. As a way to signal the compiler that it can apply certain optimizations in case no exceptions can be thrown from a method/procedure (setting up exception handling costs something)

Throwing an exception not specified in throw() clause is a mistake, however at no point is the implementation required to verify it for you. In fact it's not even possible to verify, as it includes all the possible exceptions from subroutines your subroutine calls. (possibly from other modules) It is not even possible within a single module, as is easily reduced to a halting problem :)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top