Warum sollte ich nicht jeden Block in "try"-"catch" einpacken?

Question

Ich war schon immer der Überzeugung, dass es fahrlässig ist, einen Aufruf, der eine Ausnahme werfen kann, nicht mit einem sinnvollen try-Block zu schützen.

Ich habe gerade "Sie sollten IMMER Aufrufe, die eine Ausnahme werfen können, in try-catch-Blöcke einpacken." zu dieser Frage gepostet und mir wurde gesagt, dass es sich um 'bemerkenswert schlechten Rat' handelt - Ich würde gerne verstehen, warum.

Answer 1

Eine Methode sollte eine Ausnahme nur dann abfangen, wenn sie diese auf sinnvolle Weise behandeln kann.

Ansonsten sollte sie weitergegeben werden in der Hoffnung, dass eine Methode weiter oben im Aufrufstapel damit umgehen kann.

Wie bereits von anderen erwähnt, ist es eine gute Praxis, einen nicht behandelten Ausnahme-Handler (mit Protokollierung) auf der höchsten Ebene des Aufrufstapels zu haben, um sicherzustellen, dass alle schwerwiegenden Fehler protokolliert werden.

Answer 2

Wie Mitch und andere festgestellt haben, sollten Sie keine Ausnahme abfangen, die Sie nicht auf irgendeine Weise behandeln möchten. Sie sollten darüber nachdenken, wie die Anwendung Ausnahmen systematisch behandeln wird, wenn Sie sie entwerfen. Dies führt normalerweise dazu, dass Ebenen von Fehlerbehandlung basierend auf Abstraktionen erstellt werden - zum Beispiel behandeln Sie alle SQL-bezogenen Fehler in Ihrem Datenzugriffscode, so dass der Teil der Anwendung, der mit Domänenobjekten interagiert, nicht damit konfrontiert wird, dass irgendwo im Hintergrund eine DB vorhanden ist.

Es gibt ein paar verwandte Code-Rußen, die Sie definitiv vermeiden möchten, zusätzlich zum "Alles überall fangen"-Ruß.

1. "fangen, protokollieren, neu werfen": Wenn Sie ein protokollbasiertes Protokollieren wünschen, schreiben Sie eine Klasse, die beim Entfernen des Stapels aufgrund einer Ausnahme ein Protokoll erstellt (ala std::uncaught_exception()). Alles, was Sie tun müssen, ist eine Protokollinstanz im Bereich zu deklarieren, an dem Sie interessiert sind, und voilà, Sie haben Protokollierung und keine unnötige try/catch Logik.

2. "fangen, werfen übersetzt": Dies deutet normalerweise auf ein Abstraktionsproblem hin. Wenn Sie nicht gerade eine föderierte Lösung implementieren, bei der Sie mehrere spezifische Ausnahmen in eine allgemeinere übersetzen, haben Sie wahrscheinlich eine unnötige Abstraktionsebene... und sagen Sie nicht "Vielleicht brauche ich es morgen".

3. "fangen, aufräumen, neu werfen": Dies ist eine meiner Lieblingsaversionen. Wenn Sie viel davon sehen, sollten Sie Resource Acquisition is Initialization-Techniken anwenden und den Aufräumteil im Destruktor einer janitor-Objektinstanz platzieren.

Ich halte Code, der mit try/catch Blöcken übersät ist, für ein gutes Ziel für Codeüberprüfung und Refactoring. Es zeigt an, dass entweder die Ausnahmebehandlung nicht gut verstanden wird oder der Code zu einem Amöben geworden ist und dringend einer Überarbeitung bedarf.

Answer 3

Da die nächste Frage lautet "Ich habe eine Ausnahme gefangen, was mache ich als nächstes?" Was wirst du tun? Wenn du nichts tust - das ist Fehlerversteckung und das Programm könnte einfach nicht funktionieren, ohne die Möglichkeit zu haben, herauszufinden, was passiert ist. Du musst verstehen, was genau du tun wirst, sobald du die Ausnahme gefangen hast, und nur fangen, wenn du es weißt.

Answer 4

Du musst nicht jeden Block mit try-catches abdecken, denn ein try-catch kann immer noch unbehandelte Ausnahmen abfangen, die in Funktionen weiter unten im Aufrufstapel geworfen werden. Anstatt also jedet Funktion ein try-catch haben zu lassen, kannst du eine auf der Top-Level-Logik deiner Anwendung haben. Zum Beispiel könnte es eine SaveDocument() Top-Level-Routine geben, die viele Methoden aufruft, die wiederum andere Methoden aufrufen usw. Diese Untermethoden benötigen keine eigenen try-catches, denn wenn sie eine Ausnahme werfen, wird diese immer noch vom SaveDocument()-Catch abgefangen.

Dies hat drei Vorteile: Praktisch ist es, weil du einen einzigen Ort hast, um einen Fehler zu melden: die SaveDocument() Catch-Blöcke. Es ist nicht nötig, dies in allen Untermethoden zu wiederholen, und es ist sowieso das, was du willst: einen einzigen Ort, an dem du dem Benutzer eine nützliche Diagnose über etwas geben kannst, das schief gelaufen ist.

Zweitens wird der Speichervorgang abgebrochen, wenn eine Ausnahme geworfen wird. Bei jedem try-catch in den Unterfunktionen wird, wenn eine Ausnahme geworfen wird, in den entsprechenden Catch-Block der Methode gesprungen, die Ausführung verlässt die Funktion, und es geht durch SaveDocument() weiter. Wenn bereits etwas schief gelaufen ist, möchtest du wahrscheinlich genau an dieser Stelle stoppen.

Drittens gehen alle deine Unterfunktionen davon aus, dass jeder Aufruf erfolgreich ist. Falls ein Aufruf fehlschlägt, springt die Ausführung zum Catch-Block und der nachfolgende Code wird nie ausgeführt. Das kann deinen Code viel sauberer machen. Zum Beispiel, hier ist es mit Fehlercodes:

int ret = SaveFirstSection();

if (ret == FAILED)
{
    /* irgendeine Diagnose */
    return;
}

ret = SaveSecondSection();

if (ret == FAILED)
{
    /* irgendeine Diagnose */
    return;
}

ret = SaveThirdSection();

if (ret == FAILED)
{
    /* irgendeine Diagnose */
    return;
}

So könnte es mit Ausnahmen geschrieben werden:

// diese werfen bei einem Fehler, werden im SaveDocument-Catch abgefangen
SaveFirstSection();
SaveSecondSection();
SaveThirdSection();

Jetzt ist viel klarer, was passiert.

Beachte, dass das Schreiben von code, der Ausnahmesicher ist, auf andere Weise knifflig sein kann: Du möchtest keinen Speicherlecks haben, wenn eine Ausnahme geworfen wird. Achte darauf, dass du über RAII, STL Container, Smart Pointer und andere Objekte Bescheid weißt, die ihre Ressourcen in Destruktoren freigeben, da Objekte immer vor Ausnahmen zerstört werden.

Answer 5

Herb Sutter schrieb über dieses Problem hier. Auf jeden Fall lesenswert.
Ein Vorgeschmack:

"Das Schreiben von ausnahme-sicherem Code dreht sich im Wesentlichen darum, 'try' und 'catch' an den richtigen Stellen zu schreiben." Diskutieren Sie.

Um es offen zu sagen, diese Aussage spiegelt ein grundlegendes Missverständnis von der Ausnahme-Sicherheit wider. Ausnahmen sind nur eine andere Form der Fehlermeldung, und wir wissen sicherlich, dass das Schreiben von fehlersicherem Code nicht nur darum geht, wo man Rückgabewerte überprüft und Fehlerbedingungen behandelt.

Tatsächlich stellt sich heraus, dass Ausnahme-Sicherheit selten mit dem Schreiben von 'try' und 'catch' zu tun hat - und je seltener, desto besser. Vergessen Sie auch nie, dass die Ausnahme-Sicherheit das Design eines Codes beeinflusst; es ist nie nur ein nachträglicher Gedanke, der mit ein paar zusätzlichen catch-Anweisungen nachgerüstet werden kann, als würde man sie nur als Gewürz hinzufügen.