Difference between revisions of "cpp/language/exceptions"
From cppreference.com
(Added Spanish language link. Really) |
m (std::string::at -> std::basic_string::at.) |
||
| (15 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
{{title|Exceptions}} | {{title|Exceptions}} | ||
{{cpp/language/exceptions/navbar}} | {{cpp/language/exceptions/navbar}} | ||
| − | Exception handling provides a way of transferring control and information from some point in the execution of a program to a handler associated with a point previously passed by the execution (in other words, exception handling transfers control up the call stack) | + | Exception handling provides a way of transferring control and information from some point in the execution of a program to a handler associated with a point previously passed by the execution (in other words, exception handling transfers control up the call stack). |
| − | + | Evaluating a {{rlp|throw#throw expressions|{{c/core|throw}} expression}} will thrown an exception. Exceptions can also be thrown in {{rlp|throw|other contexts}}. | |
| − | In order for an exception to be caught, the throw | + | In order for an exception to be caught, the {{c/core|throw}} expression has to be inside a {{rlp|try|{{c/core|try}} block}}, and the {{c/core|try}} block has to contain a {{rlp|catch|handler}} that matches the type of the exception object. |
| − | When declaring a function, {{rlp| | + | When declaring a function, the following specification(s) may be provided to limit the types of the exceptions a function may throw: |
| + | {{rrev|until=c++17|* {{rlp|except spec|dynamic exception specifications}}}} | ||
| + | {{rrev|since=c++11|* {{rlp|noexcept spec|noexcept specifications}}}} | ||
Errors that arise during exception handling are handled by {{lc|std::terminate}}{{rev inl|until=c++17| and {{lc|std::unexpected}}}}. | Errors that arise during exception handling are handled by {{lc|std::terminate}}{{rev inl|until=c++17| and {{lc|std::unexpected}}}}. | ||
===Usage=== | ===Usage=== | ||
| − | + | While {{c/core|throw}} expression can be used to transfer control to an arbitrary block of code up the execution stack, for arbitrary reasons (similar to {{lc|std::longjmp}}), its intended usage is error handling. | |
| − | While throw | + | |
====Error handling==== | ====Error handling==== | ||
| − | + | Throwing an exception is used to signal errors from functions, where "errors" are typically limited to only the following<ref> H. Sutter (2004) [https://www.drdobbs.com/when-and-how-to-use-exceptions/184401836 "When and How to Use Exceptions"] in Dr. Dobb's</ref><ref>H. Sutter, A. Alexandrescu (2004), "C++ Coding Standards", Item 70</ref><ref>C++ Core Guidelines [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-except I.10: Use exceptions to signal a failure to perform a required task]</ref>: | |
| − | Throwing an exception is used to signal errors from functions, where "errors" are typically limited to only the following<ref> H. Sutter (2004) [ | + | # Failures to meet the postconditions, such as failing to produce a valid return value object. |
| − | # Failures to meet the postconditions, such as failing to produce a valid return value object | + | # Failures to meet the preconditions of another function that must be called. |
| − | # Failures to meet the preconditions of another function that must be called | + | # (for non-private member functions) Failures to (re)establish a class invariant. |
| − | # (for non-private member functions) Failures to (re)establish a class invariant | + | |
In particular, this implies that the failures of constructors (see also [[cpp/language/raii|RAII]]) and most operators should be reported by throwing exceptions. | In particular, this implies that the failures of constructors (see also [[cpp/language/raii|RAII]]) and most operators should be reported by throwing exceptions. | ||
| − | In addition, so-called ''wide contract'' functions use exceptions to indicate unacceptable inputs, for example, {{lc|std:: | + | In addition, so-called ''wide contract'' functions use exceptions to indicate unacceptable inputs, for example, {{lc|std::basic_string::at}} has no preconditions, but throws an exception to indicate index out of range. |
====Exception safety==== | ====Exception safety==== | ||
| + | After the error condition is reported by a function, additional guarantees may be provided with regards to the state of the program. The following four levels of exception guarantee are generally recognized<ref>B. Stroustrup (2000), "The C++ Programming Language" [https://stroustrup.com/3rd_safe.pdf Appendix E]</ref><ref>H. Sutter (2000) "Exceptional C++"</ref><ref>D. Abrahams (2001) [https://www.boost.org/community/exception_safety.html "Exception Safety in Generic Components"]</ref>, which are strict supersets of each other: | ||
| − | + | # ''Nothrow (or nofail) exception guarantee'' — the function never throws exceptions. Nothrow (errors are reported by other means or concealed) is expected of {{rlp|destructor}}s and other functions that may be called during stack unwinding. {{rev inl|since=c++11|The {{rlp|destructor}}s are {{rlpt|noexcept}} by default.}} Nofail (the function always succeeds) is expected of swaps, {{rlp|move constructor}}s, and other functions used by those that provide strong exception guarantee. | |
| − | + | # ''Strong exception guarantee'' — If the function throws an exception, the state of the program is rolled back to the state just before the function call (for example, {{lc|std::vector::push_back}}). | |
| − | # ''Nothrow (or nofail) exception guarantee'' | + | # ''Basic exception guarantee'' — If the function throws an exception, the program is in a valid state. No resources are leaked, and all objects' invariants are intact. |
| − | # ''Strong exception guarantee'' | + | # ''No exception guarantee'' — If the function throws an exception, the program may not be in a valid state: resource leaks, memory corruption, or other invariant-destroying errors may have occurred. |
| − | # ''Basic exception guarantee'' | + | |
| − | # ''No exception guarantee'' | + | |
Generic components may, in addition, offer ''exception-neutral guarantee'': if an exception is thrown from a template parameter (e.g. from the {{tt|Compare}} function object of {{lc|std::sort}} or from the constructor of {{tt|T}} in {{lc|std::make_shared}}), it is propagated, unchanged, to the caller. | Generic components may, in addition, offer ''exception-neutral guarantee'': if an exception is thrown from a template parameter (e.g. from the {{tt|Compare}} function object of {{lc|std::sort}} or from the constructor of {{tt|T}} in {{lc|std::make_shared}}), it is propagated, unchanged, to the caller. | ||
===Exception objects=== | ===Exception objects=== | ||
| + | While objects of any complete type and cv pointers to {{c/core|void}} may be thrown as exception objects, all standard library functions throw unnamed objects by value, and the types of those objects are derived (directly or indirectly) from {{lc|std::exception}}. User-defined exceptions usually follow this pattern.<ref>D. Abrahams (2001) [https://www.boost.org/community/error_handling.html "Error and Exception Handling"]</ref><ref>isocpp.org Super-FAQ [https://isocpp.org/wiki/faq/exceptions#what-to-throw "What should I throw?"]</ref><ref>C++ Core Guidelines [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-exception-types E.14: Use purpose-designed user-defined types as exceptions (not built-in types)]</ref> | ||
| − | + | To avoid unnecessary copying of the exception object and object slicing, the best practice for handlers is to catch by reference.<ref>C++ Core Guidelines [https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Re-exception-ref E.15: Throw by value, catch exceptions from a hierarchy by reference]</ref><ref>S. Meyers (1996) "More Effective C++" Item 13</ref><ref>isocpp.org Super-FAQ [https://isocpp.org/wiki/faq/exceptions#what-to-catch "What should I catch?"]</ref><ref>H. Sutter, A. Alexandrescu (2004) "C++ Coding Standards" Item 73</ref> | |
| − | + | ||
| − | To avoid unnecessary copying of the exception object and object slicing, the best practice for | + | |
| − | === | + | ===External links=== |
| − | <references/> | + | {{elink begin}} |
| + | {{elink|<references/>}} | ||
| + | {{elink end}} | ||
| − | {{langlinks|es|ja|zh}} | + | {{langlinks|es|ja|ru|zh}} |
Latest revision as of 05:23, 8 June 2024
Exception handling provides a way of transferring control and information from some point in the execution of a program to a handler associated with a point previously passed by the execution (in other words, exception handling transfers control up the call stack).
Evaluating a throw expression will thrown an exception. Exceptions can also be thrown in other contexts.
In order for an exception to be caught, the throw expression has to be inside a try block, and the try block has to contain a handler that matches the type of the exception object.
When declaring a function, the following specification(s) may be provided to limit the types of the exceptions a function may throw:
| (until C++17) |
| (since C++11) |
Errors that arise during exception handling are handled by std::terminate and std::unexpected(until C++17).
Contents |
[edit] Usage
While throw expression can be used to transfer control to an arbitrary block of code up the execution stack, for arbitrary reasons (similar to std::longjmp), its intended usage is error handling.
[edit] Error handling
Throwing an exception is used to signal errors from functions, where "errors" are typically limited to only the following[1][2][3]:
- Failures to meet the postconditions, such as failing to produce a valid return value object.
- Failures to meet the preconditions of another function that must be called.
- (for non-private member functions) Failures to (re)establish a class invariant.
In particular, this implies that the failures of constructors (see also RAII) and most operators should be reported by throwing exceptions.
In addition, so-called wide contract functions use exceptions to indicate unacceptable inputs, for example, std::basic_string::at has no preconditions, but throws an exception to indicate index out of range.
[edit] Exception safety
After the error condition is reported by a function, additional guarantees may be provided with regards to the state of the program. The following four levels of exception guarantee are generally recognized[4][5][6], which are strict supersets of each other:
- Nothrow (or nofail) exception guarantee — the function never throws exceptions. Nothrow (errors are reported by other means or concealed) is expected of destructors and other functions that may be called during stack unwinding. The destructors are
noexceptby default.(since C++11) Nofail (the function always succeeds) is expected of swaps, move constructors, and other functions used by those that provide strong exception guarantee. - Strong exception guarantee — If the function throws an exception, the state of the program is rolled back to the state just before the function call (for example, std::vector::push_back).
- Basic exception guarantee — If the function throws an exception, the program is in a valid state. No resources are leaked, and all objects' invariants are intact.
- No exception guarantee — If the function throws an exception, the program may not be in a valid state: resource leaks, memory corruption, or other invariant-destroying errors may have occurred.
Generic components may, in addition, offer exception-neutral guarantee: if an exception is thrown from a template parameter (e.g. from the Compare function object of std::sort or from the constructor of T in std::make_shared), it is propagated, unchanged, to the caller.
[edit] Exception objects
While objects of any complete type and cv pointers to void may be thrown as exception objects, all standard library functions throw unnamed objects by value, and the types of those objects are derived (directly or indirectly) from std::exception. User-defined exceptions usually follow this pattern.[7][8][9]
To avoid unnecessary copying of the exception object and object slicing, the best practice for handlers is to catch by reference.[10][11][12][13]
[edit] External links
|
