Visual C++ Unmanaged Code: Use /EHa or /EHsc for C++ exceptions?

If I'm creating a new project in unmanaged C++, Visual Studio 2008 or greater, which exception handling model do I want to go with?

I understand that /EHa option results in less efficient code, and also catches SEH exceptions, right?

So I have been steering clear of that option and typically going with /EHsc, so that I'm only catching C++ exceptions that are actually thrown and not catching access violations and other structured execptions, in catch(...) handlers. If there is an access violation in my code, I don't want it being masked by a catch(...) {}.

I code with others who want catch(...) {} to do nothing and they even want it to do it if there is an access violation, which seems like a really bad idea to me. If there is a bug due to bad coding, you don't want to stick your fingers in your ears and loudly say "La la la la la!" so that you don't have to have the program crash? In fact, if the code is now in a bad state because of a coding error, do you really want the code to continue?

So my general thought is that /EHa creates larger/slower code and it allows programmers to get away with writing code that if a fatal bug is present, it will continue to run in an undefined state.

BTW, I'm talking about applications and service code which is wha开发者_JAVA技巧t we are writing for the most part. Not low level device drivers or anything like that.

Please weigh in with your thoughts.

/EHa does two things. First and foremost, it suppresses an optimization that omits exception filters that automatically call the destructors of local class variables if the code analyzer cannot see any code that might throw a C++ exception. This makes stack unwinding safe for any kind of exception, not just a C++ exception. Overhead for these exception filters is time on x86 and space on both x86 and x64.

And yes, it alters the behavior of catch(...), it now also filters any SEH exception, not just C++. This is indeed a gamble because you catch all the really nasty stuff, the asynchronous hardware exceptions. Although I personally don't think that catching all C++ exceptions is very defensible either, you still have but a vague idea to what degree the program state got mutated and why it failed.

Realistically, you'll need to switch to using __try/__except so that you can write your own exception filter and avoid catching the bad ones. The exception code for C++ exceptions is 0xe04d5343 ("MSC"). Using _set_se_translator() would be another approach.

I use /EHa because it's safe with .NET interop , whereas /EHsc may not be; see Destructors not called when native (C++) exception propagates to CLR component for example.

However, if for a specific bit of code the extra performance really matters and you don't need .NET (or whatever else) compatibility, then sure, /EHsc sounds fine.

Neither /EHsc nor /EHa catch most memory errors, so using these to catch access violations is a hopeless case.