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:
1
2
3
4
5
6
| try {
// code here
}
catch (int param) { cout << "int exception"; }
catch (char param) { cout << "char exception"; }
catch (...) { cout << "default exception"; }
| |
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:
1
2
3
4
5
6
7
8
9
10
11
| try {
try {
// code here
}
catch (int n) {
throw;
}
}
catch (...) {
cout << "Exception occurred";
}
|
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 a
throw specifier to it. For example:
| double myfunction (char param) throw (int);
| |
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.
1
2
| int myfunction (int param) throw(); // all exceptions call unexpected
int myfunction (int param); // normal exception handling
|
Function handling unexpected exceptions
Calls the current
unexpected handler.
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).
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
