Insufficient memory to satisfy a new request, array subscript out of bounds, arithmetic overflow, division by zero, invalid function parameters.
(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.
It is unlikely that a library function will perform error processing that will meet the unique needs of all users.
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.
The exception handlers (in the catch handlers) for that TRy block are skipped, and the program resumes execution after the last catch handler.
An exception thrown outside a try block causes a call to terminate.
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.
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.
The first matching exception handler after the try block is executed.
This is a nice way to catch related types of exceptions.
A base-class handler would catch objects of all derived-class types.
No, but it does terminate the block in which the exception is thrown.
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.
It rethrows the exception if it appears in a catch handler; otherwise, function unexpected is called.
Provide an exception specification listing the exception types that the function can throw.
Function unexecpted is called.
The try block expires, causing destructors to be called for each of these objects.