{"id":108023,"date":"2023-04-06T07:00:00","date_gmt":"2023-04-06T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=108023"},"modified":"2023-04-05T21:24:51","modified_gmt":"2023-04-06T04:24:51","slug":"20230406-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20230406-00\/?p=108023","title":{"rendered":"An ignored exception can be misinterpreted as a hang, particularly in coroutines"},"content":{"rendered":"

Consider the following function:<\/p>\n

void DoAwesomeThings()\r\n{\r\n    try {\r\n        Step1();\r\n        Step2();\r\n        Step3();\r\n    }\r\n    catch (...)\r\n    {\r\n    }\r\n}\r\n<\/pre>\n
If an exception occurs in Step2()<\/code>, then from the point of view of Do\u00adAwesome\u00adThings()<\/code>, it will appear to have hung, since control never returned.<\/p>\n
void DoAwesomeThings()\r\n{\r\n    try {\r\n        Step1();\r\n        printf(\"About to call Step2!\\n\");\r\n        Step2();\r\n        printf(\"Step2 returned!\\n\"); \/\/ never executes!\r\n        Step3();\r\n    }\r\n    catch (...)\r\n    {\r\n    }\r\n}\r\n<\/pre>\n
Now, one difference is that if you break into the debugger, you’ll find that there is no call to Step2()<\/code> anywhere on the stack, and that may be a clue that the function didn’t actually hang. But if all you have is log file, your log file just ends at<\/p>\n
About to call Step2!\r\n<\/pre>\n
and if you didn’t think about the catch (...)<\/code>, you would conclude that Step2()<\/code> is hung.<\/p>\n
Okay, so that was pretty obvious. I mean, who would make this kind of misinterpretation?<\/p>\n
Let’s make it a little less obvious: Let’s put it in a coroutine.<\/p>\n
winrt::IAsyncAction DoAwesomeThings()\r\n{\r\n    Step1();\r\n    Step2();\r\n    Step3();\r\n}\r\n<\/pre>\n
Recall that the coroutine transformation, among other things, wraps the entire coroutine body inside a try...catch<\/code>:<\/p>\n
winrt::IAsyncAction DoAwesomeThings()\r\n{\r\n    co_await promise.initial_suspend();\r\n    try {<\/span>\r\n        Step1();\r\n        printf(\"About to call Step2!\\n\");\r\n        Step2();\r\n        printf(\"Step2 returned!\\n\"); \/\/ never executes!\r\n        Step3();\r\n    } catch (...) {\r\n        promise.unhandled_exception();\r\n    }<\/span>\r\n    co_await promise.final_suspend();\r\n}\r\n<\/pre>\n
This time, when Step2()<\/code> throws an exception, it is caught by the coroutine infrastructure which calls the promise’s unhandled_exception()<\/code>. The unhandled_exception()<\/code> function typically saves the exception somewhere, so that it can be rethrown when somebody does a co_await<\/code> on the coroutine return object.<\/p>\n
In this case, what happens is that the exception is saved in the IAsyncAction<\/code> object, ready to be re-thrown by the co_await<\/code> in co_await DoAwesomeThings()<\/code>.<\/p>\n
But say you never do that co_await<\/code>.<\/p>\n
void BeReallyAwesome()\r\n{\r\n    DoAwesomeThings(); \/\/ no co_await\r\n    DoMoreAwesomeThings();\r\n}\r\n<\/pre>\n
If you look at the log file, you see the “About to call Step2!” and no “Step2 returned!”. And since you never did a co_await<\/code>, the exception that was saved in the IAsyncAction<\/code> is discarded without ever having a chance to be rethrown. Result: It looks like the coroutine simply hung.<\/p>\n
Note that each coroutine return type makes its own decision about how unhandled exceptions are dealt with, and what to do if an exception never gets rethrown. Here’s a table of some of the ones you’re like to encounter in Windows code.<\/p>\n\n\n\n\n\n\n
Coroutine type<\/th>\nUnhandled exception<\/th>\nco_await<\/code><\/th>\nUnobserved exception<\/th>\n<\/tr>\n
winrt::IAsync...<\/code><\/td>\nSave for later<\/td>\nRethrow<\/td>\nDiscarded<\/td>\n<\/tr>\n
winrt::fire_and_forget<\/code><\/td>\nFail fast<\/td>\nN\/A<\/td>\nN\/A<\/td>\n<\/tr>\n
Concurrency::task<\/code><\/td>\nSave for later<\/td>\nRethrow<\/td>\nFail fast<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
For the last two popular Windows coroutine types, the exception gets reported eventually. The fire_and_forget<\/code> crashes the process immediately, and Concurrency::task<\/code> rethrows the exception (if observed) or crashes the process (if never observed).<\/p>\n
It’s the IAsync...<\/code> that can cause exceptions to mysteriously vanish: If you simply discard them without every performing a co_await<\/code>, then you never learn of any unhandled exceptions that occurred.<\/p>\n
They just disappear.<\/p>\n
We’ll apply this knowledge next time.<\/p>\n","protected":false},"excerpt":{"rendered":"
I mean, execution seems to have stopped.<\/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-108023","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
I mean, execution seems to have stopped.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108023","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=108023"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/108023\/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=108023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=108023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=108023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}