Could you give a bullet list of practical differences/implication? I read relevant MSDN article, but my understanding asynchronous exceptions is still a bit hazy.
I am writing a test suite using Boost.Test and my compiler emits a warning that EHa should be enabled:
warning C4535: calling _set_se_translator() requires /EHa
The project itself uses only plain exceptions (from STL) and doesn’t need /EHa switch. Do I have to recompile it with /EHa switch to make the test suite work properly? My feeling is that I need /EHa for the test suit only.
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/__exceptand _set_se_translator() if that’s important to you.