Consecuencias de usar el manejo de excepciones estructuradas (SEH)?

Question

Veo que Doug Harrison ha hecho una buena declaración de lo que está "incorrecto" con el uso de excepciones estructuradas (es decir, captura) (consulte Pregunta # 3 ).Pero, ¿qué otras consecuencias hay?Por ejemplo, ¿qué sucede si tengo varios proyectos compilados con / EHA, mezclados con otros proyectos compilados con / EHS?¿Existen problemas cuando las bibliotecas están vinculadas (tiempo de compilación o tiempo de ejecución) entre otros?

Pero ese es solo un ejemplo.¿Qué otros problemas podrían haber?

Answer 1

/EHa disables an optimization. With /EHs in effect, the compiler can omit exception filters if it can be sure that no C++ exception is ever thrown by the code wrapped in a try {}. That's a small space optimization on x86 and x64, very small time optimization on x86. Problem is, those filters are needed if you catch non-C++ exceptions. The consequence is that the stack gets unwound when such an exception is caught without the destructor of a C++ object getting called. Not good, /EHa avoids it.

Mixing doesn't cause linker problems. It causes the above problem.

Yes, /EHa also makes catch(...) do a very stupid thing, it really catches everything. That ship wreck sailed a while ago though, Pokemon C++ exception handling is a bad idea too.