![\"bobby](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/07\/bobby-car.jpg\")
<\/p>\nError handling is an essential part of writing good software; therefore, the C++ core guidelines have about 20 rules for error handling.<\/p>\n
<\/p>\n
<\/p>\n
First of all. Which aspects are involved in error handling according to the guidelines:<\/p>\n
You should use exceptions for error handling. David Abrahams<\/a>, one of the founders of the Boost C++ Library and former member of the ISO C++ standardization committee, formalized in the document “Exception-Safety in Generic Components<\/a>” what exception-safety means. His Abrahams Guarantees<\/a> describe a fundamental contract if you think about exception-safety; therefore, I will mention them here in short and refer to them in the upcoming post. Here are the four levels of the contract from the already mentioned wiki page in decreasing order:<\/p>\n Often, you can not fully recover from an error. Now, you have two options.<\/p>\n First, let the program run in a simpler error state. This means the software is not fully functional anymore but provides at least reduced functionality. For example, it may not be possible for a defibrillator to apply the power but you can at least guide the operator.<\/p>\n Or, second, restart the program. Often, this is the fastest and the easiest way to get into a safe state, recover, and get fully functional. <\/p>\n The rules from the guidelines should help you to avoid the following kinds of errors:<\/p>\n After my more general remarks, let me start with the first three rules:<\/p>\n The entire rule consists only of this reason. “A consistent and complete strategy for handling errors and resource leaks is hard to retrofit into a system.” That is too little for an explanation. Error handling is a so-called cross-cutting concern such as logging or security. This means these concerns are challenging to address because they can not be easily modularized. They affect the entire software.<\/p>\n Exception safety is an integral part of the interface design and has to be, therefore, addressed from the first beginning. Now the question is: What is an interface? My definition of an interface is quite broad.<\/p>\n An interface is a protocol between two components<\/strong>. One component may be a function, an object, a sub-system, or the entire system. This component may also be an external dependency, such as hardware or an operating system.<\/p>\n You have two ways to communicate at the boundary level: regularly and irregularly. Regular communication is the functional aspect of the interface. Or, to say it differently: What the system should do. Irregular communication stands for the non-functional aspects. The non-functional aspect specifies how a system should perform. A big part of the non-functional aspects is exception-handling or what can go wrong. Often the non-functional aspects are just called quality attributes.<\/p>\n From a general point of view, an interface consists of two components. Each component has to fulfill a special kind of contract.<\/p>\n These terms go back Bertrand Meyer<\/a> and are known as design by contract<\/a>.<\/p>\n <\/p>\n <\/p>\n By Fabuio<\/a> – Own work<\/span>, CC0<\/a>, Link<\/a><\/p>\n Before I continue, I should mention that we may get contracts<\/a> with C++20.<\/p>\n The consequence of this rule is that the caller of the function should handle the exception with a try\/catch<\/span> statement. The critical question is: When should you throw an exception? Here are typical use cases:<\/p>\n This is, in my opinion, one of the worst misuses of exceptions. Exceptions are a kind of goto<\/span> statement. Maybe your code guidelines forbid you to use goto<\/span> statements. Therefore, you devised a clever idea: use exceptions for control flow. In the following example, the exception is used in the success case.<\/p>\n <\/p>\n\n
<\/a><\/sup><\/li>\n\n
<\/code><\/li>\n<\/code><\/li>\n\n
E.1: Develop an error-handling strategy early in a design<\/a><\/h3>\n
\n
![\"Design](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/07\/Design_by_contract.png\")
<\/p>\nE.2: Throw an exception to signal that a function can\u2019t perform its assigned task<\/a><\/h3>\n
\n
<\/code><\/li>\nE.3: Use exceptions for error handling only<\/a><\/h3>\n
\n\/\/ don't: exception not used for error handling<\/span>\r\nint<\/span> find_index<\/span>(vector<<\/span>string>&<\/span> vec, const<\/span> string&<\/span> x)\r\n{\r\n try {\r\n for<\/span> (gsl::<\/span>index i =<\/span> 0<\/span>; i <<\/span> vec.size(); ++<\/span>i)\r\n if<\/span> (vec[i] ==<\/span> x) throw<\/span> i; \/\/ found x<\/span>\r\n } catch<\/span> (int<\/span> i) {\r\n return<\/span> i;\r\n }\r\n return<\/span> -<\/span>1<\/span>; \/\/ not found<\/span>\r\n}\r\n<\/pre>\n<\/div>\n