Visual C ++ Unmanaged Code: Use / EHa oder / EHsc für C ++ Ausnahmen?

Question

Wenn ich ein neues Projekt in nicht verwalteten C ++, Visual Studio 2008 oder mehr zu schaffen, die Ausnahmebehandlung Modell kann ich mit gehen?

Ich verstehe, dass / EHa Option führt zu weniger effizienten Code, und auch SEH Ausnahmen abfängt, nicht wahr?

Also ich Lenkung war klar von dieser Möglichkeit und in der Regel mit / EHsc gehen, so dass ich fange nur C ++ Ausnahmen, die tatsächlich geworfen werden und nicht Zugriffsverletzungen zu kontrollieren und anderen strukturierten execptions, in catch (...) Handler . Wenn es eine Zugriffsverletzung in meinem Code ist, ich will nicht, dass es durch eine Rast maskiert wird (...) {}.

I-Code mit anderen, die fangen wollen (...) {} nichts zu tun, und sie wollen auch sie es tun, wenn es eine Zugriffsverletzung ist, die wie eine wirklich schlechte Idee, mir scheint. Wenn Sie einen Fehler dort wegen schlechten Codierung ist, wollen Sie sich nicht die Finger in die Ohren stecken und laut sagen: „La la la la la!“ so dass Sie nicht über den Programmabsturz haben müssen? In der Tat, wenn der Code jetzt in einem schlechten Zustand ist aufgrund eines Codierungsfehlers, wollen Sie wirklich der Code fortfahren?

So mein allgemeiner Gedanke ist, dass / EHa größer / langsamer Code erstellt und ermöglicht es Programmierer mit dem Schreiben von Code wegzuzukommen, dass, wenn ein fataler Fehler vorhanden ist, wird es weiterhin in einem undefinierten Zustand ausgeführt werden.

BTW, ich spreche über Anwendungen und Service-Code das ist, was wir für den größten Teil schreiben. Nicht geringere Gerätetreiber oder so etwas.

Bitte wiegen Sie sich mit Ihren Gedanken.

Answer 1

/ EHa macht zwei Dinge. In erster Linie, es unterdrückt eine Optimierung dass auslässt Ausnahmefilter, dass die Destruktoren der lokalen Klassenvariablen automatisch aufrufen, wenn der Code Analyzer keinen Code sehen können, die eine C ++ Ausnahme auslösen könnten. Dies macht Stack Abwickeln sicher für jede Art von Ausnahme, nicht nur eine C ++ Ausnahme. Overhead für diese Ausnahmefilter ist Zeit auf x86 und Raum sowohl auf x86 und x64.

Und ja, es verändert das Verhalten der catch (...), ist es nun filtert auch alle SEH Ausnahme, nicht nur C ++. Dies ist in der Tat ein Glücksspiel, weil Sie alle wirklich böse Dinge fangen, die asynchrone Hardware Ausnahmen. Obwohl ich persönlich glaube nicht, dass alle C ++ fangen Ausnahmen entweder sehr vertretbar ist, haben Sie immer noch, aber eine vage Vorstellung, was Grad wurde der Programmzustand mutiert und warum versagt es.

Realistisch betrachtet, werden Sie auf Schalter müssen mit __try/__except so dass Sie Ihre eigenen Ausnahmefilter schreiben und vermeiden die schlechten zu kontrollieren. Der Ausnahmecode für C ++ Ausnahmen ist 0xe04d5343 ( "MSC"). Mit _set_se_translator () würde ein anderer Ansatz.

Answer 2

Ich benutze / EHa weil es sicher ist, mit .NET-Interop, während / EHsc möglicherweise nicht; finden Sie unter Destruktoren nicht aufgerufen, wenn nativer (C ++) Ausnahme pflanzt sich auf CLR Komponente zum Beispiel.

Wenn jedoch für einen bestimmten Stück Code die zusätzliche Leistung wirklich zählt, und Sie brauchen nicht .NET (oder was auch immer) Kompatibilität, dann sicher, / EHsc hört sich gut an.

Weder / EHsc noch / EHa fangen die meisten Speicherfehler zu verwenden, da diese zu fangen Zugriffsverletzungen ein hoffnungsloser Fall ist.