![\"disappointment](\"https:\/\/www.modernescpp.com\/wp-content\/uploads\/2018\/08\/disappointment-3151237_1280.jpg\")
<\/p>\nToday’s post is about the right way to throw and catch exceptions. This means when you should throw and how you should catch an exception.<\/p>\n
<\/p>\n
<\/p>\n
Here are the rules for today:<\/p>\n
swap<\/code> must never fail<\/a><\/li>\n- E.17: Don\u2019t try to catch every exception in every function<\/a><\/li>\n
- E.18: Minimize the use of explicit
try<\/code>\/catch<\/code><\/a><\/li>\n<\/ul>\nLet me jump directly into the first one.<\/p>\n
E.14: Use purpose-designed user-defined types as exceptions (not built-in types)<\/a><\/h2>\nYou should not use standard exception types or even built-in types as an exception. Here are the two that don’t from the guidelines:<\/p>\n
A built-in type<\/h3>\n\nvoid<\/span> my_code<\/span>() \/\/ Don't<\/span>\r\n{\r\n \/\/ ...<\/span>\r\n throw<\/span> 7<\/span>; \/\/ 7 means \"moon in the 4th quarter\"<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n\r\nvoid<\/span> your_code<\/span>() \/\/ Don't<\/span>\r\n{\r\n try {\r\n \/\/ ...<\/span>\r\n my_code();\r\n \/\/ ...<\/span>\r\n }\r\n catch<\/span>(int<\/span> i) { \/\/ i == 7 means \"input buffer too small\"<\/span>\r\n \/\/ ...<\/span>\r\n }\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
In this case, the exception is just an int<\/span> without any semantics. What 7 <\/span>means stands in the comment, but should better be a self-describing type. The comment can be wrong. To be sure, you must look up the documentation to get an idea. You can not attach any meaningful information to an exception of kind int<\/span>. If you have a 7<\/span>, I assume you use at least the numbers 1 to 6 for your exception handling. 1<\/span> meaning an unspecific error, and so on. This is too sophisticated, error-prone, and hard to read and maintain.<\/p>\nA standard exception<\/h3>\n\nvoid<\/span> my_code<\/span>() \/\/ Don't<\/span>\r\n{\r\n \/\/ ...<\/span>\r\n throw<\/span> runtime_error{\"moon in the 4th quarter\"<\/span>};\r\n \/\/ ...<\/span>\r\n}\r\n\r\nvoid<\/span> your_code<\/span>() \/\/ Don't<\/span>\r\n{\r\n try {\r\n \/\/ ...<\/span>\r\n my_code();\r\n \/\/ ...<\/span>\r\n }\r\n catch<\/span>(const<\/span> runtime_error&<\/span>) { \/\/ runtime_error means \"input buffer too small\"<\/span>\r\n \/\/ ...<\/span>\r\n }\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
Using a standard exception instead of a built-in type is better because you can attach additional information to an exception or build hierarchies of exceptions. This is better but not good. Why? The exception is too generic. It’s just a runtime_error<\/span>. Image the function my_code<\/span> is part of an input sub-system. If the caller of the function catches the exception by std::runtime_error,<\/span> he has no idea if it was a generic error, such as “input buffer too small<\/span>” or a sub-system-specific error, such as “input device is not connected<\/span>“.<\/p>\nTo overcome these issues, derive your specific exception from std::exception<\/span>. Here is a short example to give you an idea:<\/p>\n\nclass<\/span> InputSubSystemException<\/span>:<\/span> public<\/span> std::<\/span>exception{\r\n const<\/span> char<\/span>*<\/span> what() const<\/span> noexcept override {\r\n return<\/span> \"Provide more details to the exception\"<\/span>;\r\n }\r\n};\r\n<\/pre>\n<\/div>\nNow, the client of the input sub-system can specifically catch the exception via catch(const InputSubSystemException& ex)<\/span>. You can also refine the exception hierarchy by deriving from the class InputSubSystemException.<\/span><\/p>\n<\/p>\nE.15: Catch exceptions from a hierarchy by reference<\/a><\/h2>\nIf you catch an exception from a hierarchy by value, you may become a victim of slicing.<\/p>\n
Imagine you derive from InputSubSystemException<\/span> (rule E.14) a new exception class USBInputException<\/span> and catch the exception by-value of type InputSubSystemException.<\/span> <\/span>Now, an exception of type<\/span><\/span> <\/span><\/span>USBInputException<\/span> is thrown.<\/p>\n\nvoid<\/span> subSystem<\/span>(){\r\n \/\/ ...<\/span>\r\n throw<\/span> USBInputException<\/span>();<\/span>\r\n \/\/ ...<\/span>\r\n}\r\n\r\nvoid<\/span> clientCode<\/span>(){\r\n try{\r\n subSystem();\r\n }\r\n catch<\/span>(InputSubSystemException e) { \/\/ slicing may happen<\/span>\r\n \/\/ ...<\/span>\r\n }\r\n}\r\n<\/pre>\n<\/div>\n <\/p>\n
By catching the USBInputException<\/span> by-value to InputSubSystemException, <\/span>slicing kicks in, and e<\/span> has the simpler type InputSubSystemException. <\/span>Please read the details of slicing in my previous post: C++ Core Guidelines: Rules about Don’ts. <\/a>
<\/span><\/p>\nTo say it explicitly:<\/p>\n
\n- Catch your exception by const reference and only by reference if you want to modify the exception.<\/li>\n
- If you rethrow an exception e in the exception handler, use throw and not throw e. In the second case, e would be copied.
<\/span><\/span><\/li>\n<\/ol>\nE.16: Destructors, deallocation, and swap<\/code> must never fail<\/a><\/h2>\nThis rule is quite obvious. Destructors and deallocations should never throw because their any reliable way to handle an exception during the destruction of an object.<\/p>\n
swap <\/span>is often used as a basic building block for implementing copy and move semantics for a type. If an exception happens during swap, <\/span>you are left with a non-initialized or not fully initialized object. Read more about the noexcept swap here: C++ Core Guidelines: Comparison, Swap, and Hash<\/a>.
<\/span><\/p>\nThe following two rules for the adequate usage of try and except are pretty similar.<\/p>\n
E.17: Don\u2019t try to catch every exception in every function<\/a> and E.18: Minimize the use of explicit try<\/code>\/catch<\/code><\/a><\/h2>\nFrom the control-flow perspective, try\/catch<\/span> has much in common with the goto <\/span>statement. This means if an exception is thrown, the control flow directly jumps to the exception handler which is maybe in a totally different function of even sub-system. In the end, you may get spaghetti code<\/a>; meaning code that has difficult to predict and maintain control flow.<\/p>\n