{"id":96706,"date":"2017-07-28T07:00:00","date_gmt":"2017-07-28T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=96706"},"modified":"2019-03-13T01:14:38","modified_gmt":"2019-03-13T08:14:38","slug":"20170728-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170728-00\/?p=96706","title":{"rendered":"Can I throw a C++ exception from a structured exception?"},"content":{"rendered":"

A customer wanted to know if it was okay to throw a C++ exception from a structured exception. <\/p>\n

They explained that they didn’t want to compile their project with the \/EHa<\/code> switch<\/a>, which instructs the compiler to use the exception-handling model that catches both asynchronous (structured) exceptions as well as synchronous (C++) exceptions. In other words, the catch<\/code> statement will catch both explicitly thrown C++ exceptions (raised by the throw<\/code> statement) as well as exceptions generated by the operating system, either due to notifications from the CPU (such as an access violation or divide-by-zero) or explicit calls to Raise­Exception<\/code>. <\/p>\n

The customer explained that they didn’t want to use \/EHa<\/code> because doing so significantly impairs compiler optimizations and results in larger code size. But on the other hand, they do want to catch the asynchronous (structured) exceptions. <\/p>\n

So they had a fiendish plan. <\/p>\n

Their fiendish plan is to install an unhandled exception filter which turns around and throws the C++ exception. That way, a structured exception will result in a standard C++ exception, but without the code generation penalties of the \/EHa<\/code> compiler option. <\/p>\n

\n\/\/ This clever function is an exception filter that converts\n\/\/ asynchronous exceptions (structured exception handling)\n\/\/ to synchronous exceptions (C++ exceptions).\n\nLONG WINAPI CleverConversion(\n    EXCEPTION_POINTERS* ExceptionInfo)\n{\n    \n    auto record = ExceptionInfo->ExceptionRecord;\n\n    std::string message;\n    ... build a message based on the exception code and\n    other parameters ...\n\n    throw std::exception(message.c_str());\n}\n\nint sample_function(int* p)\n{\n    try {\n        printf(\"About to dereference the pointer %p\\n\", p);\n        return *p;\n    } catch (std::exception& e) {\n        Log(e.what());\n    }\n    return 0;\n}\n\nint __cdecl main(int argc, char **argv)\n{\n    SetUnhandledExceptionFilter(CleverConversion);\n\n    return sample_function(nullptr);\n}\n<\/pre>\n
Neat trick, huh? All the benefits of \/EHa<\/code> without the overhead! <\/p>\n
Well, except that they found that it didn’t always work. <\/p>\n
In the example above, the catch<\/code> did catch the C++ exception, but if they took out the printf<\/code>, then the exception was not caught. <\/p>\n
\nint sample_function(int* p)\n{\n    try {\n        return *p;\n    } catch (std::exception& e) {\n        Log(e.what());          \/\/ exception not caught!\n    }\n    return 0;\n}\n<\/pre>\n
The customer wanted to know why the second version didn’t work. <\/p>\n
Actually the first version isn’t guaranteed to work either. It happens to work because the compiler must consider the possibility that the printf<\/code> function might throw a C++ exception. The printf<\/code> function is not marked as noexcept<\/code>, so the possibility is in play. (Not that you’d expect it to be marked as such, seeing as it’s a C function, and C doesn’t have exceptions.) When the access violation is raised as a structured exception, the Clever­Conversion<\/code> function turns it into a C++ exception and throws it, at which point the try<\/code> block catches it. But the try<\/code> block is not there for the Clever­Conversion<\/code> exception. It’s there to catch any exceptions coming out of printf<\/code>, and you just happened to be lucky that it caught your exception too. <\/p>\n
In the second example, there is no call to printf<\/code>, so the compiler says, “Well, nothing inside this try<\/code> block can throw a C++ exception, so I can optimize out the try\/catch<\/code>.” You would also have observed this behavior if there were function calls inside the try<\/code> block, if the function calls were all to functions that were marked noexcept<\/code> or if the compiler could prove that they didn’t throw any C++ exceptions (say, because the function is inlined). <\/p>\n
This answers the question, but let’s try to look at the whole story. <\/p>\n
    \n
  1. We want to use \/EHa<\/code>.<\/li>\n
  2. But the documentation says that \/EHa<\/code>     results in less efficient code.     We want more efficient code, not less.<\/li>\n
  3. Aha, we found this trick that lets us convert     asynchronous exceptions to synchronous ones.     Now we get all the benefits of \/EHa<\/code>     without any of the costs!<\/li>\n<\/ol>\n
    It looks like you found some free money on the ground, but is it really free money? <\/p>\n
    The customer seems to think that the \/EHa<\/code> option results in less efficient code simply because the compiler team is a bunch of jerks and secretly hates you. <\/p>\n
    No, that’s not why the \/EHa<\/code> option results in less efficient code. The possibility that any memory access or arithmetic operation could trigger an exception significantly impairs optimization opportunities. It means that all variables must be stable at the point memory accesses occur. <\/p>\n
    Consider the following code fragment: <\/p>\n
    \nclass Reminder\n{\npublic:\n    Reminder(char* message) : m_message(message) { }\n    ~Reminder() { std::cout << \"don't forget to \"\n                            << m_message << std::endl; }\n\n    void UpdateMessage(char* message) { m_message = message; }\n\nprivate:\n    char* m_message;\n};\n\nvoid NonThrowingFunction() noexcept;\nvoid DoSomethingElse(); \/\/ might throw\n\nvoid sample_function()\n{\n    try {\n        Reminder reminder(\"turn off the lights\");\n        if (NonThrowingFunction()) {\n            reminder.UpdateMessage(\"feed the cat\");\n        }\n        DoSomethingElse();\n    } catch (std::exception& e) {\n        Log(e.what());\n    }\n}\n<\/pre>\n
    If compiling without \/EHa<\/code>, the compiler knows that the Non­Throwing­Function<\/code> function cannot throw a C++ exception, so it can delay the store of reminder.<\/code>m_message<\/code> to just before the call to Do­Something­Else<\/code>. In fact, it is like to do so because it avoids a redundant store. <\/p>\n
    The pseudo-code for this function might look like this: <\/p>\n
    \n    allocate 4 bytes in local frame for reminder\n\nl1:\n    call NonThrowingFunction\n    if result is zero\n        load r1 = \"turn off the lights\"\n    else\n        load r1 = \"feed the cat\"\n    endif\n    store r1 to reminder.m_message\n    call DoSomethingElse\nl2:\n    std::cout << \"don't forget to \"\n              << r1 << std::endl;\nl3:\n\n    clean up local frame\n    return\n\nif exception occurs between l1 and l2\n    std::cout << \"don't forget to \"\n              << reminder.m_message << std::endl;\n    fall through\n\nif exception occurs between l2 and l3\n    if exception is std::exception\n        Log(e.what())\n        goto l3\n    else\n        continue exception search\n    endif\n<\/pre>\n
    Notice that we optimized out a redundant store by delaying the initialization of reminder<\/code>, and we enregistered reminder.<\/code>m_message<\/code> in the common code path. Delaying the initialization of reminder<\/code> is not an optimization available to \/EHa<\/code> because of the possibility that Non­Throwing­Function<\/code> might raise an asynchronous exception that gets converted to a synchronous one: <\/p>\n
    \n    allocate 4 bytes in local frame for reminder\n\nl0:\n    \/\/ cannot delay initialization of reminder\n    load r1 = \"turn off the lights\"\n    store r1 to reminder.m_message<\/font>\n\nl1:\n    call NonThrowingFunction\n    if result is nonzero\n        load r1 = \"feed the cat\"\n        store r1 to reminder.m_message\n    endif<\/font>\n    call DoSomethingElse\nl2:\n    std::cout << \"don't forget to \"\n              << r1 << std::endl;\nl3:\n\n    clean up local frame\n    return\n\nif exception occurs between l1 and l2\n    std::cout << \"don't forget to \"\n              << reminder.m_message << std::endl;\n    fall through\n\n\/\/ and there is a new exception region<\/font>\nif exception occurs between l0 and l1<\/font>, or between l2 and l3\n    if exception is std::exception\n        Log(e.what())\n        goto l3\n    else\n        continue exception search\n    endif\n<\/pre>\n
    The extra code is necessary in order to ensure that the reminder<\/code> variable is in a stable state before calling Non­Throwing­Function<\/code>. In general, if you turn on \/EHa<\/code>, the compiler must ensure that every object which is accessed outside the try<\/code> block (either explicitly in code or implicitly via an unwind destructor) is stable in memory before performing any operation that could result in an asynchronous exception, such as accessing memory. <\/p>\n
    This requirement that variables be stable in memory comes at a high cost, because it not only forces redundant stores to memory, but it also prohibits various types of optimizations based on out-of-order operations. <\/p>\n
    The Clever­Conversion<\/code> is basically a manual replication of what \/EHa<\/code> does, but lying to the compiler and saying, “Um, yeah, don’t worry about asynchronous exceptions.” <\/p>\n
    Observe what happens if an asynchronous exception occurs inside Non­Throwing­Function<\/code> even though you compiled without the \/EHa<\/code> flag: <\/p>\n
    We destruct the reminder<\/code> object, which means printing the m_message<\/code> to std::<\/code>cout<\/code>. But the non-\/EHa<\/code> version did not ensure that reminder.<\/code>m_message<\/code> was stable. Indeed, if an exception occurs inside Non­Throwing­Function<\/code>, we will try to print reminder.<\/code>m_message<\/code> anyway, even though it is an uninitialized variable. <\/p>\n
    Printing an uninitialized variable is probably not what the program intended. <\/p>\n
    So a more complete answer to the scenario is “Yes, it is technically possible to throw a C++ exception from a structured exception handler, but doing so requires that the program be compiled with \/EHa<\/code> in order to avoid undefined behavior.” <\/p>\n
    And given that avoiding the \/EHa<\/code> flag was the whole purpose of the exercise, the answer to the specific scenario is, “No, this doesn’t work. Your program will behave in undefined ways.” <\/p>\n","protected":false},"excerpt":{"rendered":"
    Technically okay, but it’s unusual and doesn’t solve your problem.<\/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-96706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    Technically okay, but it’s unusual and doesn’t solve your problem.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96706","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=96706"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96706\/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=96706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=96706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=96706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}