CLR Tasks, PPL tasks, JavaScript Promises, and Windows Runtime asynchronous actions and operations can fail in two ways.<\/p>\n
Task<\/code>, task<\/code>, IAsyncAction<\/code>, or IAsyncOperation<\/code>. “Synchronous failure.”<\/li>\n- They can return a
Task<\/code>, task<\/code>, IAsyncAction<\/code>, or IAsyncOperation<\/code> which completes with an exception. “Asynchronous failure.”<\/li>\n<\/ul>\nSynchronous failures are raised at the point you call the method; you can think of them as “immediate failure”. Asynchronous failure are raised at the point you check the result; you can think of them as “delayed failure”.<\/p>\n
\n\n\nFramework<\/th>\n Synchronous failure<\/th>\n Asynchronous failure<\/th>\n<\/tr>\n \nC#<\/td>\n var task = o.DoSomethingAsync()<\/code><\/td>\ntask.Result<\/code>
\nawait task<\/code><\/code><\/td>\n<\/tr>\n\nPPL<\/td>\n auto task = o->DoSomethingAsync()<\/code><\/td>\ntask.get()<\/code>
\nco_await task<\/code><\/td>\n<\/tr>\n\nC++\/WinRT<\/td>\n auto op = o.DoSomethingAsync()<\/code><\/td>\nop.GetResults()<\/code>
\nco_await op<\/code><\/td>\n<\/tr>\n\nJavaScript<\/td>\n var p = o.DoSomethingAsync()<\/code><\/td>\np.catch()<\/code>
\nawait p<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nA customer reported that they were getting exceptions from some code, which they couldn’t understand because they thought they were handling exceptions.<\/p>\n
\/\/ C++ with PPL\r\nusing namespace Concurrency;\r\nusing namespace Platform;\r\n\r\ntask<String^>\r\nWidget::GetNameAsync()\r\n{\r\n return m_doodad->GetNameAsync() \/\/ crash here\r\n .then([](task<String^> outerTask) {\r\n String^ name;\r\n\r\n try {\r\n name = outerTask.get();\r\n } catch (...) {\r\n }\r\n\r\n return name;\r\n }, task_continuation_context::use_arbitrary());\r\n}\r\n<\/pre>\nThe code wraps the outerTask.get()<\/code> inside a try<\/code> block, so that should catch all the exceptions that come out of the m_doodad->GetNameAsync()<\/code> task.<\/p>\nAnd that’s true, it does catch all the exceptions that come out of the task.<\/p>\n
But the exception that crashed didn’t come out of the task!<\/p>\n
The debugger pointed at the line that raised the exception: It was from the call to GetNameAsync()<\/code> itself, before it even returned a task. The customer got so focused on the Concurrency Runtime that they forgot about the basic rules of C++: If you want to catch an exception, you have to do it inside a try<\/code> block.<\/p>\nIn order to catch that exception, the call to GetNameAsync()<\/code> must itself be inside a try<\/code> block.<\/p>\ntask<String^>\r\nWidget::GetNameAsync()\r\n{\r\n task<String^> nameTask;\r\n try {<\/span>\r\n nameTask = m_doodad->GetNameAsync();\r\n } catch (...) { <\/span>\r\n return task_from_result<String^>(nullptr);<\/span>\r\n } <\/span>\r\n\r\n return nameTask.then([](task<String^> outerTask) {\r\n String^ name;\r\n\r\n try {\r\n name = outerTask.get();\r\n } catch (...) {\r\n }\r\n\r\n return name;\r\n }, task_continuation_context::use_arbitrary());\r\n}\r\n<\/pre>\nI separated the return m_doodad->GetNameAsync().then()<\/code> into two steps:<\/p>\n task<String^> nameTask = m_doodad->GetNameAsync();\r\n return nameTask.then(...);\r\n<\/pre>\nThe try<\/code> statement inside the then<\/code> lambda deals with exceptions that come out of the task. We just need another try<\/code> to deal with the exceptions that occur while trying to produce the task:<\/p>\n task<String^> nameTask;\r\n try {<\/span>\r\n nameTask = m_doodad->GetNameAsync();\r\n } catch (...) { <\/span>\r\n return task_from_result<String^>(nullptr);<\/span>\r\n } <\/span>\r\n<\/pre>\nIf an exception occurs, we catch it and return an already-completed task that produces an empty string. Otherwise, we hook up the continuation that deals with the task completion as before.<\/p>\n
Once you see how the expression was taken apart, you can combine them again, putting the entire statement inside a giant try<\/code> block, even though it’s only the ->GetNameAsync()<\/code> that we’re interested in. (Most languages with exceptions make it cumbersome to catch exceptions that come out of part of an expression, so most people just expand the scope of the try<\/code> to include the entire statement.)<\/p>\ntask<String^>\r\nWidget::GetNameAsync()\r\n{\r\n try {<\/span>\r\n return m_doodad->GetNameAsync()\r\n .then([](task<String^> outerTask) {\r\n String^ name;\r\n\r\n try {\r\n name = outerTask.get();\r\n } catch (...) {\r\n }\r\n\r\n return name;\r\n }, task_continuation_context::use_arbitrary());\r\n } catch (...) { <\/span>\r\n return task_from_result<String^>(nullptr);<\/span>\r\n } <\/span>\r\n}\r\n<\/pre>\nNote that if the customer had been using PPL with co_await<\/code> support, the try<\/code> block would naturally have enclosed both the production of the task as well as handling for its completion: The inability to wrap just part of an expression in a try<\/code> block actually helps you write correct code this time:<\/p>\ntask<String^>\r\nWidget::GetNameAsync()\r\n{\r\n try {\r\n co_return co_await m_doodad->GetNameAsync();\r\n } catch (...) {\r\n co_return nullptr;\r\n }\r\n}\r\n<\/pre>\nOne catch with this rewrite is that co_await<\/code> of a Concurrency Runtime task<\/code> does not let you control the task continuation context. It always uses get_current_winrt_context()<\/code> when awaiting tasks, and CallbackContext::Same<\/code> when awaiting Windows Runtime asynchronous actions and operations.<\/p>\n","protected":false},"excerpt":{"rendered":"Fail me now or fail me later.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-107727","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Fail me now or fail me later.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107727","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=107727"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107727\/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=107727"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107727"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107727"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}