Absolute C++ (4th Edition) part 78. KEY BENEFIT: C++ programming concepts and techniques are presented in a straightforward style using understandable language and code. KEY TOPICS: C++ Basics; Flow of Control; Function Basics; Parameters and Overloading; Arrays; Structures and Classes; Constructors; Operator Overloading, Friends, and References; Strings; Pointers and Dynamic Arrays; Separate Compilation and Namespaces; Streams and File I/O; Recursion; Inheritance; Polymorphism and Virtual Functions; Templates; Linked Data Structures; Exception Handling; Standard Template Library; Patterns and UML. MARKET: Useful for both beginning and intermediate C++ programmers. . | Exception Handling Basics 777 void someFunction throw Empty exception list so all exceptions invoke unexpected . void someFunction All exceptions of all types are treated normally. The default action of unexpected is to end the program. You need not use any special include or using directives to gain the default behavior of unexpected . You normally have no need to redefine the behavior of unexpected however the behavior of unexpected can be changed with the function set_unexpected. If you need to use set_unexpected you should consult a more advanced book for the details. Keep in mind that an object of a derived class is also an object of its base class. So if D is a derived class of class B and B is in the exception specification then a thrown object of class D will be treated normally since it is an object of class B. However no automatic type conversions are done. If double is in the exception specification that does not account for throwing an int value. You would need to include both int and double in the exception specification. One final warning Not all compilers treat the exception specification as they are Warning supposed to. Some compilers essentially treat the exception specification as a comment with those compilers the exception specification has no effect on your code. This is another reason to place all exceptions which might be thrown by your functions in the throw specification. This way all compilers will treat your exceptions the same way. Of course you could get the same compiler consistency by not having any throw specification at all but then your program would not be as well documented and you would not get the extra error checking provided by compilers that do use the throw specification. With a compiler that does process the throw specification your program will terminate as soon as it throws an exception that you did not anticipate. Note that this is a runtime behavior but which runtime behavior you get depends on your compiler. Pitfall .
