Wrap-Up

2017-11-03 09:05:03

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 `tHRow`s an exception and the appropriate exception handler begins executing. Now suppose that the exception handler itself `throw`s 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 `throw`s an exception from a deeply nested function and still has the `catch` handler following the `TRy` block enclosing the call chain catch the exception.

Answers to Self Review Exercises

Exercises

Категории