{"id":110830,"date":"2025-02-03T07:00:00","date_gmt":"2025-02-03T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110830"},"modified":"2025-02-03T08:28:08","modified_gmt":"2025-02-03T16:28:08","slug":"20250203-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250203-00\/?p=110830","title":{"rendered":"On trying to log an exception as it leaves your scope"},"content":{"rendered":"

A customer wanted to log exceptions that emerged from a function, so they used the WIL scope_exit<\/code> object to specify a block of code to run during exception unwinding.<\/p>\n

void DoSomething()\r\n{\r\n    auto logException = wil::scope_exit([&] {\r\n        Log(\"DoSomething failed\",\r\n            wil::ResultFromCaughtException());\r\n    });\r\n\r\n    \u27e6 do stuff that might throw exceptions \u27e7\r\n\r\n    \/\/ made it to the end - cancel the logging\r\n    logException.release();\r\n}\r\n<\/pre>\n
They found, however, that instead of logging the exception, the code in the scope_exit<\/code> was crashing.<\/p>\n
They debugged into the Result\u00adFrom\u00adCaught\u00adException<\/code> function, which eventually  reaches something like this<\/a>:<\/p>\n
try\r\n{\r\n    throw;\r\n}\r\ncatch (\u27e6 blah blah \u27e7)\r\n{\r\n    \u27e6 blah blah \u27e7\r\n}\r\ncatch (\u27e6 blah blah \u27e7)\r\n{\r\n    \u27e6 blah blah \u27e7\r\n}\r\ncatch (...)\r\n{\r\n    \u27e6 blah blah \u27e7\r\n}\r\n<\/pre>\n
The idea is that the code rethrows the exception, then tries to catch it in various ways, and when it is successful, it uses the caught object to calculate a result code.<\/p>\n
And that’s where the problem lies.<\/p>\n
It’s sort of implied by the name Result\u00adFrom\u00adCaught\u00adException<\/code> that it tries to calculate a result from an exception that was caught. But the scope_exit<\/code> functor is called during unwinding that results from an uncaught<\/i> exception.<\/p>\n
There is no caught exception to get a result from!<\/p>\n
The C++ language says that a rethrowing throw<\/code> rethrows the exception that is being handled, where “being handled” roughly means “is executing the body of its catch<\/code> clause”. If you try a rethrowing throw when there is no exception being handled, then it’s straight to jail. (Formally, std::terminate<\/code>.)<\/p>\n
The solution, then, is to put the Result\u00adFrom\u00adCaught\u00adException<\/code> somewhere inside a catch<\/code> block, like perhaps this:<\/p>\n
void DoSomething()\r\n{\r\n    try {\r\n        \u27e6 do stuff that might throw exceptions \u27e7\r\n    } catch (...) {\r\n        Log(\"DoSomething failed\",\r\n            wil::ResultFromCaughtException());\r\n        throw;\r\n    })\r\n}\r\n<\/pre>\n
After logging the exception, we rethrow it so that the search for a handler can continue.<\/p>\n
Bonus chatter<\/b>: You can avoid a layer of indentation by using  function-try<\/a>.<\/p>\n
void DoSomething() try<\/span>\r\n{\r\n    \u27e6 do stuff that might throw exceptions \u27e7\r\n} <\/span>catch (...) {                           <\/span>\r\n    Log(\"DoSomething failed\",             <\/span>\r\n        wil::ResultFromCaughtException());<\/span>\r\n    throw;                                <\/span>\r\n}                                         <\/span>\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"
You can’t watch it from an object on the outside.<\/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-110830","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You can’t watch it from an object on the outside.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110830","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=110830"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110830\/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=110830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}