{"id":110629,"date":"2024-12-11T07:00:00","date_gmt":"2024-12-11T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110629"},"modified":"2024-12-11T09:23:02","modified_gmt":"2024-12-11T17:23:02","slug":"20241211-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20241211-00\/?p=110629","title":{"rendered":"What is the CONTINUE_IF_FAILED<\/CODE> equivalent of RETURN_IF_FAILED<\/CODE>?"},"content":{"rendered":"

A customer who used the Windows Implementation Library<\/a> couldn’t find a CONTINUE_IF_FAILED<\/code> macro, the counterpart to the existing RETURN_IF_FAILED<\/code> macro, so they wrote their own:<\/p>\n

#define CONTINUE_IF_FAILED(hr) \\\r\n    if (FAILED(hr)) { LOG_HR(hr); continue; }\r\n<\/pre>\n
This version has a serious problem: It evaluates its argument twice.<\/p>\n
Their sample usage went something like this:<\/p>\n
for (auto&& item : items)\r\n{\r\n    wil::com_ptr<IAttachment> attachment;\r\n    CONTINUE_IF_FAILED(item->GetAttachment(&attachment));\r\n\r\n    wil::unique_cotaskmem_ptr name;\r\n    CONTINUE_IF_FAILED(attachment->GetName(&name));\r\n\r\n    if (wcscmp(name.get(), L\"Special\") == 0) {\r\n        HandleSpecial(item);\r\n    }\r\n}\r\n<\/pre>\n
After expanding the macro one level, we have<\/p>\n
for (auto&& item : items)\r\n{\r\n    wil::com_ptr<IAttachment> attachment;\r\n    if (FAILED(item->GetAttachment(&attachment))) {<\/span>\r\n        LOG_HR(item->GetAttachment(&attachment));  <\/span>\r\n        continue;                                  <\/span>\r\n    }                                              <\/span>\r\n\r\n    wil::unique_cotaskmem_ptr name;\r\n    if (FAILED(attachment->GetName(&name))) {<\/span>\r\n        LOG_HR(attachment->GetName(&name));  <\/span>\r\n        continue;                            <\/span>\r\n    }                                        <\/span>\r\n\r\n    if (wcscmp(name.get(), L\"Special\") == 0) {\r\n        HandleSpecial(item);\r\n    }\r\n}\r\n<\/pre>\n
Notice that in both cases, we attempt the operation, and if it fails, we attempt it again (!) and log the result of the second attempt.<\/p>\n
Fortunately in this case, the Get<\/code> methods have no side effects, so calling them twice is mostly harmless. You can imagine cases where this could be a problem, say, if the method was something like Toggle\u00adState<\/code>.<\/p>\n
Furthermore, the second call might not fail for the same reason as the first call. Maybe the first call failed due to a transient error (server not responding, low memory), and the second call succeeds. Your code logs a success code, and you’ll be scratching your head when you study your logs trying to figure out why the code gave up on a successful call.<\/p>\n
You should build your solution out of the existing RETURN_IF_FAILED<\/code> macro.  The wil wiki even explains how<\/a>: Use a lambda to wrap the block you want to early-exit from without exiting the entire function.<\/p>\n
for (auto&& item : items)\r\n{\r\n    [&] {\r\n        wil::com_ptr<IAttachment> attachment;\r\n        RETURN_IF_FAILED(item->GetAttachment(&attachment));\r\n\r\n        wil::unique_cotaskmem_ptr name;\r\n        RETURN_IF_FAILED(attachment->GetName(&name));\r\n\r\n        if (wcscmp(name.get(), L\"Special\") == 0) {\r\n            HandleSpecial(item);\r\n        }\r\n\r\n        return S_OK;\r\n    }();\r\n}\r\n<\/pre>\n
You have all of the RETURN_IF_<\/code> macros at your disposal inside the lambda. You can use RETURN_IF_FAILED<\/code>, RETURN_HR_IF<\/code>, RETURN_IF_FAILED_EXPECTED<\/code>, and so on, so no need to create CONTINUE_IF_<\/code> variants of everything. And all of the error logging and reporting settings related to RETURN_IF_<\/code> will still work.<\/p>\n","protected":false},"excerpt":{"rendered":"
Be careful how you write it, or better: Don’t write it at all.<\/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-110629","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Be careful how you write it, or better: Don’t write it at all.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110629","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=110629"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110629\/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=110629"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110629"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110629"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}