Conseguenze dell'utilizzo della gestione delle eccezioni strutturate (SEH)?

Question

Vedo Doug Harrison ha fatto una buona dichiarazione di ciò che è "sbagliato" con l'uso (cioè catturare) eccezioni strutturate (vedere Domanda # 3 ).Ma quali altre conseguenze ci sono?Ad esempio, cosa succede se ho diversi progetti compilati con / EHA, mescolati con altri progetti compilati con / EHS?Esistono problemi quando le librerie sono collegate (tempo di compilazione o tempo di esecuzione) con l'altro?

Ma questo è solo un esempio.Quali altri problemi potrebbero esserci?

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.