Conséquences de l'utilisation de la manipulation des exceptions structurées (SEH)?

Question

Je vois que Doug Harrison a fait une bonne déclaration de ce qui est "faux" avec l'utilisation d'exceptions structurées (c.-à-d. Attraper) (voir question n ° 3 ).Mais quelles autres conséquences y a-t-il?Par exemple, que se passe-t-il si j'ai plusieurs projets compilés avec / EHA, mélangés à d'autres projets compilés avec / EHS?Y a-t-il des problèmes lorsque les bibliothèques sont liées (compilation ou temps d'exécution) avec eachother?

Mais ce n'est qu'un exemple.Quelles autres problèmes pourraient-il y avoir?

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.