{"id":107307,"date":"2022-10-21T07:00:00","date_gmt":"2022-10-21T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107307"},"modified":"2022-10-21T08:37:59","modified_gmt":"2022-10-21T15:37:59","slug":"20221021-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221021-00\/?p=107307","title":{"rendered":"What happens if my C++ exception handler itself raises an exception?"},"content":{"rendered":"

Last time, we looked at what happens if your structured exception handler raises its own structured exception<\/a>. Today, we’ll look at the C++ version of the same question: What happens if my C++ exception handler itself raises an exception?<\/p>\n

Let’s look at this sample code fragment:<\/p>\n\n\n\n
\n
try\r\n{\r\n    Block1;\r\n}\r\ncatch (Type1 ex1)\r\n{\r\n    Block2;\r\n}\r\ncatch (Type2 const& ex2)\r\n{\r\n    Block3;\r\n}\r\n\/* finally { destructors; } *\/<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If an exception is thrown out of Block1<\/code>, C++ looks for a matching catch<\/code> block,\u00b9 and neither clause matches, then the search for a handler continues at the next outer scope. If no scope handles the exception, then the process terminates via std::terminate<\/code>.<\/p>\n
The bodies of the catch<\/code> blocks are not in scope of the try<\/code> statement, so if an exception is thrown by Block2<\/code> or Block3<\/code>, the search for a handler does not include the catch (Type1 ex1)<\/code> or catch (Type2 const& ex1)<\/code> clauses.<\/p>\n
There is no finally<\/code> clause in C++ try<\/code>\/catch<\/code> statements, but the equivalent functionality is obtained by putting the desired cleanup code in destructors of objects declared in Block1<\/code>. If control exits Block1<\/code> due to an exception, and one of the objects in that block throws an exception in its destructor, then the rules of C++ are that the process terminates immediately via std::terminate<\/code>. This is different from Windows structured exceptions and C# exceptions.<\/p>\n
In the code sample above, I’ve put these destructors in a pseudo-“finally” clause, just so I will have a place to annotate them.<\/p>\n
Another difference from Windows structured exceptions is the case of an exception that occurs while performing type matching: If a catch<\/code> clause captures the exception object by value, the exception object is constructed from the thrown object. And if that constructor throws an exception, the C++ standard says that the process terminates via std::terminate<\/code>.\u00b2 (This is also different from Windows structured exceptions.)<\/p>\n
Here’s an annotated version of the above discussion:<\/p>\n\n\n\n\n\n\n\n\n
\n
try\r\n{\r\n    Block1;\r\n}<\/pre>\n<\/td>\n
Under consideration<\/td>\n<\/tr>\n
\n
catch (Type1 ex1)<\/pre>\n<\/td>\n
std::terminate<\/code><\/td>\n<\/tr>\n
\n
{\r\n    Block2;\r\n}<\/pre>\n<\/td>\n
Not considered<\/td>\n<\/tr>\n
\n
catch (Type2 const& ex2)<\/pre>\n<\/td>\n
std::terminate<\/code><\/td>\n<\/tr>\n
\n
{\r\n    Block3;\r\n}<\/pre>\n<\/td>\n
Not considered<\/td>\n\u00a0<\/td>\n<\/tr>\n
\n
\/* finally { destructors; } *\/<\/pre>\n<\/td>\n
It’s complicated<\/td>\n\u00a0<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The “It’s complicated” for the pseudo-finally clause applies because both behaviors are possible, depending on why the destructors are running.<\/p>\n
    \n
  • If Block1<\/code> is exiting normally, then exceptions that occur in destructors are catchable by the try<\/code> statement.<\/li>\n
  • If Block1<\/code> is exiting due to an exception, then std::terminate<\/code> is called.<\/li>\n<\/ul>\n
    Note that both cases can occur in the same try<\/code> statement! Suppose the Block1<\/code> runs to the final close-brace, and then it becomes time to run the destructors. Suppose there are two objects inside the Block1<\/code> that require destruction. The first one to destruct throws an exception. This is an exception thrown during normal exit of Block1<\/code>, so the exception is catchable. But before we try to catch that exception, we need to run the second destructor. If this second destructor also throws an exception, we are now in the case of a destructor throwing an exception during exception handling, and this results in std::terminate<\/code>.<\/p>\n
    \u00b9 This search is done sequentially, so it will try to match Type1<\/code> first, and Type2 const&<\/code> second. As a result, reordering your catch<\/code> clauses can result in changes in behavior if the thrown object matches multiple catch<\/code> clauses.<\/p>\n
    \u00b2 In general, you should catch things by reference. This removes the possibility of exceptions during the construction of the catch<\/code> argument, and it also avoids slicing if the thrown object is a derived class of the thing you’re catching.<\/p>\n","protected":false},"excerpt":{"rendered":"
    And comparing to the handling of structured exceptions.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-107307","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    And comparing to the handling of structured exceptions.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107307","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=107307"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107307\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=107307"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107307"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107307"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}