Macht es Sinn, Ausnahmen im Haupt (...) zu fangen?

Question

ich einige Code in einem Projekt gefunden, das so aussieht:

int main(int argc, char *argv[]) 
{ 
    // some stuff 

try { 
    theApp.Run(); 
} catch (std::exception& exc) { 
    cerr << exc.what() << std::endl; 
    exit(EXIT_FAILURE); 
} 
return (EXIT_SUCCESS); 
} 

Ich verstehe nicht, warum die Ausnahmen abgefangen werden. Wenn dies nicht der Fall wäre, würde die Anwendung einfach beendet und die Ausnahme gedruckt.

Sehen Sie einen guten Grund, Ausnahmen zu erfassen?

---

EDIT: Ich stimme zu, dass es gut ist, den Ausnahmefehler zu drucken. Wäre es jedoch nicht besser, die Ausnahme zu wiederholen? Ich habe das Gefühl, dass wir es hier schlucken ...

Answer 1

Wenn eine Ausnahme nicht abgefangen wird, definiert der Standard nicht, ob der Stapel abgewickelt wird. So werden auf einigen Plattformen Destruktoren aufgerufen, und bei anderen wird das Programm sofort beendet. Das Abfangen auf der obersten Ebene stellt sicher, dass Destruktoren immer aufgerufen werden.

Also, wenn Sie nicht unter dem Debugger laufen, ist es wahrscheinlich klug, alles zu fangen: (...) sowie std :: Ausnahme. Dann kann Ihr Anwendungscode selbst bei einer schwerwiegenden Ausnahme mit RAII aufräumen. In vielen Fällen müssen Sie nicht wirklich aufräumen, da das Betriebssystem dies für Sie erledigt. Sie ziehen es jedoch vor, wenn möglich, sauber von Remote-Diensten zu trennen, und möglicherweise befinden sich außerhalb des Prozesses Ressourcen wie Named Pipes/Mutexes, die Sie lieber zerstören als auslecken möchten.

Das Auftauchen der Ausnahme in main scheint mir von begrenztem Nutzen, da Sie bereits den Kontext verloren haben, in dem es ursprünglich geworfen wurde. Ich nehme an, dass das Auffangen einer nicht abgefangenen Ausnahme im Debugger lauter ist, als nur den Fehler in std :: cerr zu protokollieren, also wäre das erneute Abrufen der intelligente Zug, wenn es eine Chance gibt, die Protokollierung zu verpassen.

Wenn der Debugger unerwartete Bedingungen im Debugmodus abfangen soll, die im Freigabemodus eine Ausnahme auslösen, die schließlich zu einem Exit führt, gibt es andere Möglichkeiten, als die Ausnahme nicht abgefangen zu lassen, damit der Debugger sie sieht .Zum Beispiel könnten Sie Assert-Makros verwenden. Natürlich hilft das nicht bei unerwarteten und unvorhersehbaren Bedingungen, wie Hardware-Ausnahmen, wenn Sie SEH auf .NET verwenden.

Answer 2

Warum sagen Sie, dass die Ausnahme gedruckt würde? Dies ist nicht das typische Verhalten der C++ - Laufzeit. Im besten Fall können Sie erwarten, dass sein Typ gedruckt wird.

Darüber hinaus hinterlässt dieses Programm einen "Fehler" -Status, während eine Ausnahme einen Abbruch-durch-Abbruch-Status (d. H. Mit einem Signal, das in dem Beendigungscode angegeben ist) verursachen kann.

Answer 3

Dies ist ein globaler Catch-Block. Es ist üblich, anstelle eines kryptischen Ausnahmeausdrucks eine nette und vom Benutzer verstandene Nachricht ('Interner Fehler') anzuzeigen. Dies kann aus dem spezifischen Codeblock nicht offensichtlich sein, aber es ist im Allgemeinen eine gute Idee.

Answer 4

Try-Catch in der Hauptfunktion verbirgt die Ausnahme vom Debugger. Ich würde sagen, es ist nicht gut.

Auf der anderen Seite, Kunden werden nicht erwartet, Debugger zu haben, so dass das Abfangen von Ausnahmen ist nett. Es ist also gut.

Persönlich erhalte ich alle Ausnahmen in der Hauptfunktion, wenn ich einen Release-Build mache, und ich mache das nicht, wenn ich eine Debug-Konfiguration erstelle.

Answer 5

Werfen Sie einen Blick auf die C++ Bibel, d. H. Stroustrup, er hat ein Beispiel, das auch in Applied C++ - Programmierung wiederholt wird. Die Begründung lautet:

Answer 6

Ein einfaches Beispiel für eine Situation, in der der Stapel nicht entspannen: Eine Liste von
Why destructor is not called on exception?

Situationen, in denen Ausnahmen die Anwendung eher zu beenden, verursachen können, als der Stapel zu entspannen.
Why destructor is not called on exception?

Wenn eine Ausnahme nicht auf jeder Ebene gefangen und würde entkommen main(), dann wird die Umsetzung zu nennen erlaubt terminate() eher, dass der Stapel Abwickeln (ja, das mich auch überrascht).

Als Ergebnis erhalte ich immer alle Ausnahmen in main().

int main() 
{ 
    try 
    { 
    } 
    catch(std::exception const& e) 
    { /* LOG */ 
     // optimally rethrow 
    } 
    catch(...) // Catch anything else. 
    { /* LOG */ 
     // optimally rethrow 
    } 
} 

Um beim Auffangen von Problemen während des Debuggens zu helfen. Leiten Sie Ihre Ausnahmen von std :: exception ab und hängen Sie den Haltepunkt im Konstruktor für std :: exception fest.

Answer 7

Gemäß der Windows-Spezifikation darf die main nicht geworfen werden. (praktisch ergibt es die Nachricht, die fragt, ob Sie den Fehlerbericht an Microsoft senden möchten)