Exception type:
Derived types (scattered throughout different library headers)
-
bad_alloc
- Exception thrown on failure allocating memory (class )
-
bad_cast
- Exception thrown on failure to dynamic cast (class )
-
bad_exception
- Exception thrown by unexpected handler (class )
-
bad_function_call
- Exception thrown on bad call (class )
-
bad_typeid
- Exception thrown on typeid of null pointer (class )
-
bad_weak_ptr
- Bad weak pointer (class )
-
ios_base::failure
- Base class for stream exceptions (public member class )
-
logic_error
- Logic error exception (class )
-
runtime_error
- Runtime error exception (class )
Indirectly (through logic_error ):
-
domain_error
- Domain error exception (class )
-
future_error
- Future error exception (class )
-
invalid_argument
- Invalid argument exception (class )
-
length_error
- Length error exception (class )
-
out_of_range
- Out-of-range exception (class )
Indirectly (through runtime_error ):
-
overflow_error
- Overflow error exception (class )
-
range_error
- Range error exception (class )
-
system_error
- System error exception (class )
-
underflow_error
- Underflow error exception (class )
Multiple handlers (i.e., catch
expressions) can be chained; each one with a different parameter type. Only the handler whose argument type matches the type of the exception specified in the throw
statement is executed.
If an ellipsis (...
) is used as the parameter of catch
, that handler will catch any exception no matter what the type of the exception thrown. This can be used as a default handler that catches all exceptions not caught by other handlers:
| |
In this case, the last handler would catch any exception thrown of a type that is neither
int
nor
char
.
After an exception has been handled the program, execution resumes after the try-catch block, not after the
throw
statement!.
It is also possible to nest try-catch
blocks within more external try
blocks. In these cases, we have the possibility that an internal catch
block forwards the exception to its external level. This is done with the expression throw;
with no arguments. For example:
| |
Exception specification
Older code may contain dynamic exception specifications. They are now deprecated in C++, but still supported. A dynamic exception specification follows the declaration of a function, appending athrow
specifier to it. For example:
| |
This declares a function called
myfunction
, which takes one argument of type
char
and returns a value of type
double
. If this function throws an exception of some type other than
int
, the function calls
std::unexpected instead of looking for a handler or calling
std::terminate.
If this
throw
specifier is left empty with no type, this means that
std::unexpected is called for any exception. Functions with no
throw
specifier (regular functions) never call
std::unexpected, but follow the normal path of looking for their exception handler.
| |
void unexpected();
By default, the unexpected handler calls terminate. But this behavior can be redefined by calling set_unexpected.
This function is automatically called when a function throws an exception that is not listed in its dynamic-exception-specifier (i.e., in its
throw
specifier).
This function is provided so that the unexpected handler can be explicitly called by a program, and works even if set_unexpected has not been used to set a custom unexpected handler (calling terminate in this case).