Wrap-Up

Answers to Self Review Exercises

16.1	Insufficient memory to satisfy a new request, array subscript out of bounds, arithmetic overflow, division by zero, invalid function parameters.
16.2	(a) Exception handling is designed to handle infrequently occurring situations that often result in program termination, so compiler writers are not required to implement exception handling to perform optimally. (b) Flow of control with conventional control structures generally is clearer and more efficient than with exceptions. (c) Problems can occur because the stack is unwound when an exception occurs and resources allocated prior to the exception might not be freed. (d) The "additional" exceptions make it more difficult for the programmer to handle the larger number of exception cases.
16.3	It is unlikely that a library function will perform error processing that will meet the unique needs of all users.
16.4	A program that terminates abruptly could leave a resource in a state in which other programs would not be able to acquire the resource, or the program itself might not be able to reacquire a "leaked" resource.
16.5	The exception handlers (in the catch handlers) for that TRy block are skipped, and the program resumes execution after the last catch handler.
16.6	An exception thrown outside a try block causes a call to terminate.
16.7	The form catch(...) catches any type of exception thrown in a try block. An advantage is that all possible exceptions will be caught. A disadvantage is that the catch has no parameter, so it cannot reference information in the thrown object and cannot know the cause of the exception.
16.8	This causes the search for a match to continue in the next enclosing TRy block if there is one. As this process continues, it might eventually be determined that there is no handler in the program that matches the type of the thrown object; in this case, terminate is called, which by default calls abort. An alternative terminate function can be provided as an argument to set_terminate.
16.9	The first matching exception handler after the try block is executed.
16.10	This is a nice way to catch related types of exceptions.
16.11	A base-class handler would catch objects of all derived-class types.
16.12	No, but it does terminate the block in which the exception is thrown.
16.13	The exception will be processed by a catch handler (if one exists) associated with the try block (if one exists) enclosing the catch handler that caused the exception.
16.14	It rethrows the exception if it appears in a catch handler; otherwise, function unexpected is called.
16.15	Provide an exception specification listing the exception types that the function can throw.
16.16	Function unexecpted is called.
16.17	The try block expires, causing destructors to be called for each of these objects.

Exercises

16.18	List various exceptional conditions that have occurred throughout this text. List as many additional exceptional conditions as you can. For each of these exceptions, describe briefly how a program typically would handle the exception, using the exception-handling techniques discussed in this chapter. Some typical exceptions are division by zero, arithmetic overflow, array subscript out of bounds, exhaustion of the free store, etc.
16.19	Under what circumstances would the programmer not provide a parameter name when defining the type of the object that will be caught by a handler?
16.20	A program contains the statement throw;   Where would you normally expect to find such a statement? What if that statement appeared in a different part of the program?
16.21	Compare and contrast exception handling with the various other error-processing schemes discussed in the text.
16.22	Why should exceptions not be used as an alternate form of program control?
16.23	Describe a technique for handling related exceptions.
16.24	Until this chapter, we have found that dealing with errors detected by constructors can be awkward. Exception handling gives us a better means of handling such errors. Consider a constructor for a String class. The constructor uses new to obtain space from the free store. Suppose new fails. Show how you would deal with this without exception handling. Discuss the key issues. Show how you would deal with such memory exhaustion with exception handling. Explain why the exception-handling approach is superior.
16.25	Suppose a program tHRows an exception and the appropriate exception handler begins executing. Now suppose that the exception handler itself throws the same exception. Does this create infinite recursion? Write a program to check your observation.
16.26	Use inheritance to create various derived classes of runtime_error. Then show that a catch handler specifying the base class can catch derived-class exceptions.
16.27	Write a conditional expression that returns either a double or an int. Provide an int catch handler and a double catch handler. Show that only the double catch handler executes, regardless of whether the int or the double is returned.
16.28	Write a program that generates and handles a memory-exhaustion exception. Your program should loop on a request to create dynamic memory through operator new.
16.29	Write a program illustrating that all destructors for objects constructed in a block are called before an exception is thrown from that block.
16.30	Write a program illustrating that member object destructors are called for only those member objects that were constructed before an exception occurred.
16.31	Write a program that demonstrates several exception types being caught with the catch(...) exception handler.
16.32	Write a program illustrating that the order of exception handlers is important. The first matching handler is the one that executes. Attempt to compile and run your program two different ways to show that two different handlers execute with two different effects.
16.33	Write a program that shows a constructor passing information about constructor failure to an exception handler after a try block.
16.34	Write a program that illustrates rethrowing an exception.
16.35	Write a program that illustrates that a function with its own try block does not have to catch every possible error generated within the TRy. Some exceptions can slip through to, and be handled in, outer scopes.
16.36	Write a program that throws an exception from a deeply nested function and still has the catch handler following the TRy block enclosing the call chain catch the exception.