{"id":107429,"date":"2022-11-21T07:00:00","date_gmt":"2022-11-21T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107429"},"modified":"2022-11-19T19:36:10","modified_gmt":"2022-11-20T03:36:10","slug":"20221121-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221121-00\/?p=107429","title":{"rendered":"What kind of caller diagnostic information can I get from exceptions thrown by C++\/WinRT and wil?"},"content":{"rendered":"

C++\/WinRT throws winrt::hresult_error<\/code> to represent COM exceptions. The wil<\/a> framework throws Result\u00adException<\/code> for this purpose. How do they interact, and what diagnostic information do they provide?<\/p>\n

C++\/WinRT hresult_error<\/code> uses Ro\u00adOriginate\u00adError<\/code> to generate a stowed exception<\/i> which records, among other things, a stack trace for the current thread. This stack trace is stored as part of the hresult_error<\/code> in the form of a IRestrictedErrorInfo<\/code>.<\/p>\n

The wil framework by default does not use Ro\u00adOriginate\u00adError<\/code>, so there is no captured stack trace. However, it does capture the file name and line number in the Failure\u00adInfo<\/code> that is stored in the Result\u00adException<\/code>. The Failure\u00adInfo<\/code> also contains information to let you correlate multiple failures and see which ones are manifestations of the same underlying failure.<\/p>\n

Here’s a little table of what we have so far:<\/p>\n\n\n\n\n\n\n\n
\u00a0<\/th>\nC++\/WinRT<\/th>\nwil<\/th>\n<\/tr>\n
Thrown type<\/td>\nhresult_error<\/code><\/td>\nResult\u00adException<\/code><\/td>\n<\/tr>\n
Stack trace in thrown object<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
File\/line number in thrown object<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
Recorded in wil error log<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Things get more complicated if you include wil\/result_originate.h<\/code>: This tells wil to call Ro\u00adOriginate\u00adError<\/code> before throwing the exception, thereby capturing a stack trace. The stack trace is not explicitly saved in the exception object, however. It is stored in a thread-local object that can be retrieved via GetErrorInfo()<\/code>, and many parts of the system (including C++\/WinRT) understand how to retrieve and preserve this extended information, though determining whether any specific scenario preserves the extended information requires investigation.<\/p>\n

So now we have this:<\/p>\n\n\n\n\n\n\n\n\n
\u00a0<\/th>\nC++\/WinRT<\/th>\nwil<\/th>\n<\/tr>\n
Thrown type<\/td>\nhresult_error<\/code><\/td>\nResult\u00adException<\/code><\/td>\n<\/tr>\n
Stack trace in thrown object<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
Stack trace in thread data<\/td>\nYes<\/td>\nRequires result_originate.h<\/code><\/td>\n<\/tr>\n
File\/line number in thrown object<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
Recorded in wil error log<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

But wait, we’re not done yet. There’s another header file that affects how wil throws exceptions, and that’s wil\/cppwinrt.h<\/code>. This header file enables various C++\/WinRT+wil interop features, including exception handling. Exceptions propagated by the C++\/WinRT library (for example, by check_hresult()<\/code>) are filtered through wil, which logs them through its own error logging channel. However, since the file and line number were generated from the __FILE__<\/code> and __LINE__<\/code> preprocessor symbols captured by the THROW_IF_FAILED<\/code> macro, C++\/WinRT cannot capture file and line number information about the origination point, so you don’t get line number information in your wil trace log. But you still get a stack trace in the hresult_error<\/code> object.<\/p>\n

Exceptions that are thrown explicitly via throw hresult_error()<\/code> do not go through wil filtering.<\/p>\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/th>\nC++\/WinRT<\/th>\nwil<\/th>\n<\/tr>\n
no wil\/cppwinrt.h<\/code><\/th>\nwith wil\/cppwinrt.h<\/code><\/th>\n\u00a0<\/th>\n<\/tr>\n
throw hresult_error<\/code><\/th>\ncheck_hresult<\/code><\/th>\nTHROW_IF_FAILED<\/code><\/th>\n<\/tr>\n
Thrown type<\/td>\nhresult_error<\/code><\/td>\nhresult_error<\/code><\/td>\nhresult_error<\/code><\/td>\nResult\u00adException<\/code><\/td>\n<\/tr>\n
Stack trace in thrown object<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
Stack trace in thread data<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\nRequires result_originate.h<\/code><\/td>\n<\/tr>\n
File\/line number in thrown object<\/td>\nNo<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
Recorded in wil error log<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

But wait, we’re not finished yet. The wil framework alters its behavior if C++\/CX is enabled. If so, then it throws a Platform::Exception^<\/code> instead of a wil::Result\u00adException<\/code>. The Platform::Exception^<\/code> captures a stack trace but not file\/line number information.<\/p>\n\n\n\n\n\n\n\n\n\n\n
\u00a0<\/th>\nC++\/WinRT<\/th>\nwil<\/th>\n<\/tr>\n
no wil\/cppwinrt.h<\/code><\/th>\nwith wil\/cppwinrt.h<\/code><\/th>\nno C++\/CX<\/th>\nwith C++\/CX<\/th>\n<\/tr>\n
throw hresult_error<\/code><\/th>\ncheck_hresult<\/code><\/th>\nTHROW_IF_FAILED<\/code><\/th>\nTHROW_IF_FAILED<\/code><\/th>\n<\/tr>\n
Thrown type<\/td>\nhresult_error<\/code><\/td>\nhresult_error<\/code><\/td>\nhresult_error<\/code><\/td>\nResult\u00adException<\/code><\/td>\nException^<\/code><\/td>\n<\/tr>\n
Stack trace in thrown object<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\nNo<\/td>\nYes<\/td>\n<\/tr>\n
Stack trace in thread data<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\nRequires result_originate.h<\/code><\/td>\nYes<\/td>\n<\/tr>\n
File\/line number in thrown object<\/td>\nNo<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\nNo<\/td>\n<\/tr>\n
Recorded in wil error log<\/td>\nNo<\/td>\nNo<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

A survey of the current state of the art.<\/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-107429","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

A survey of the current state of the art.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107429","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=107429"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107429\/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=107429"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107429"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107429"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}