Gutes Verhältnis von Catch-Anweisungen zu Codezeilen

Question

Gibt es Faustregeln darüber, wie viele Catch-Anweisungen pro Quellcodezeile in einer großen Software erwartet werden? Zum Beispiel zeigt Visual Studio in einem Stück Software, das in C# geschrieben wurde, etwa 350 Zeilen mit dem Wort "catch" und cloc Berichte, dass wir etwa 160.000 SLOC, 30.000 kommentierte Zeilen und 15.000 leere Zeilen haben. 160 KB/350 entspricht ungefähr 467 Zeilen Code pro Fanganweisung.

Aber nehmen Sie das mit einem Körnchen Salz, weil wir Standard C# Formatierung mit Klammern auf ihren eigenen Zeilen verwenden, also wer weiß, wie viele Zeilen sind nur einzelne Klammern aus der 160k, und dass 160k zählt einige Dateien in der Baum, die nicht mehr in der Anwendung kompiliert werden, etc. Ich könnte vermuten, dass das "nützliche" Verhältnis näher bei 1 Fang pro 400 LOC liegt.

Zumindest nicht zu meiner Überraschung fehlte uns eine halbkritische Ausnahme, die in einem leeren catch-Block gefangen wurde, also gehe ich jetzt durch die Codebasis und drucke zumindest die Ausnahme auf die Debug-Konsole aus als eine vorübergehende Maßnahme oder genauer auf die Ausnahme gefangen werden. Dies wird natürlich die Anzahl der Fänge erhöhen, die wir in der gesamten Anwendung haben, aber wird es uns irgendwo näher an die "akzeptable" Zone bringen? Ich habe keine Ahnung, ob 1 Catch per 467 LOC gut ist, nur okay, oder sogar schrecklich.

---

Ich bin sehr wohl bewusst warum nicht leere catch-Blöcke zu verwenden. Die anderen/vorherigen Betreuer waren faul. Und da die nächste Version dieses Produkts zeitkritisch ist, habe ich derzeit nicht die Zeit, alle 300 (?) Schlechten Fanganweisungen richtig zu reparieren und den ordnungsgemäßen Betrieb der Software zu verifizieren (natürlich haben wir so gut wie keine Automatisierung Testen, um das zu erleichtern: /).

Ich war nur auf der Suche nach einem "Bauchgefühl", wie oft man versuchen sollte, Try-Fange zu sehen. Es gibt ein paar Antworten, die sagen, dass es kontextsensitiv ist, was ich irgendwie ahnte, mir aber nicht sicher war.

Answer 1

Es ist sehr schwer, eine allgemeine Zahl zu geben - es wird wirklich davon abhängen, was die Anwendung tun soll und ob sie Operationen ausführen muss, die auf eine wiederherstellbare Weise fehlschlagen können.

Der große Punkt zu entfernen ist, dass leere Catch-Blöcke eine wirklich, wirklich schlechte Idee sind. Das ist viel wichtiger als Codezeilen pro Catch-Block.

Answer 2

Sie sollten keine Ausnahmen erfassen, es sei denn, Sie gehen tatsächlich zu Handle ihnen. Wenn der Handler die Ausnahme nicht rückgängig machen oder den Wert auf andere Weise hinzufügen kann, sollten Sie zulassen, dass die Ausnahme an jemanden weitergegeben wird, der sie verarbeiten kann.

Answer 3

Ich würde solche Metriken vollständig ignorieren. Das Zählen von Codezeilen ist nicht unbedingt eine nützliche Kennzahl - besonders, wenn Sie nach Kennzahlen suchen.

Die wirkliche Antwort hier wird vollständig vom Kontext abhängen. Die "richtige" Anzahl von catch-Anweisungen ist die Anzahl der try/catch-Blöcke, die erforderlich sind, um die möglichen Ausnahmen zu behandeln, die Sie korrekt behandeln. Sie sollten einen try/catch-Block um eine eventuell auftretende Ausnahme haben, die Sie richtig behandeln können. Wenn Sie nicht damit umgehen können (oder nicht damit umgehen wollen), lassen Sie es nach oben propagieren - fangen Sie es nicht ein.

Die Anzahl der Fangblöcke hängt vollständig davon ab, welche Art von Code Sie schreiben.Wenn Sie beispielsweise Netzwerkcode schreiben, werden Sie wahrscheinlich mehr Ausnahmebehandlungen an Ort und Stelle haben (da Netzwerke von Natur aus eher Probleme haben, die behandelt werden müssen).

Answer 4

Als eine sehr grobe Metrik ist meine Faustregel, mindestens eine in jedem Ereignishandler zu haben, der die Ausnahme protokolliert.

In Bezug auf die anderen Methoden, ich bevorzuge sie try-catch-free; Abgesehen davon gibt es viele Male, dass ich catch-Blöcke hinzugefügt habe, um problematischen Fehlermeldungen einen Status hinzuzufügen ("parameter = value"), und dann einfach zum primären Handler "werfen". Wenn Sie mit Ihren Fehlerbehebungen gut umgehen können, führt dieser Ansatz zu viel totem Code.