EHsc vc EHa (synchronous vs asynchronous exception handling)

原文：http://stackoverflow.com/questions/4573536/ehsc-vc-eha-synchronous-vs-asynchronous-exception-handling

 

When you use /EHsc, the compiler will only emit code for exception filters when it can detect that the code wrapped in the try {} block might throw a C++ exception. An exception filter ensures that the destructor of any local C++ objects get called when the stack is unwound while handling an exception. It makes RAII work.

That's an optimization, space and time for x86 code, space for x64 code. Space because it can omit the exception filter code, which is modest btw. Time because on x86 it can avoid registering the exception filter upon entering the try {} block. Very modest btw. x64 uses a different way to find exception filters, it is table-based.

The key phrase in the first paragraph is "might throw a C++ exception". On Windows there are other sources of exceptions. Like the "a" in /EHa, asynchronous exceptions that are raised by the hardware. Things like floating point exceptions, division by zero, and the all-mighty access violation exception. But also notably the kind of exceptions that are raised by code that you might interop with. Like managed code, basically anything that runs in a VM.

When you want to make your objects safe for these kind of exceptions as well then you'll need to use /EHa, that tells the compiler to always register the exception filter.

Beware of a nasty side-effect of /EHa, it makes catch(...) swallow all exceptions. Including the ones you should never catch, like AV and SO. Look at __try/__except and _set_se_translator() if that's important to you.