Ich führe Code durch FxCop und bin gerade dabei, alle nicht-brechenden Verletzungen zu beseitigen.
Der Code selbst hat einige Instanzen von try / catch-Blöcken, die nur allgemeine Ausnahmen abfangen;
%Vor%Jetzt wissen wir alle, dass das eine schlechte Übung ist, aber ich dachte, ich könnte es richtig machen - aber FxCop hat andere Ideen!
Angenommen, der Code im try-Block könnte eine IO-Ausnahme auslösen - und nur eine IO-Ausnahme. Es sollte nichts falsch daran sein, dies zu tun:
%Vor% Aber FxCop stimmt mir nicht zu ... es kennzeichnet dies immer noch als Verstoß, weil ich System.Exception abfange.
Ist das wirklich eine schlechte Übung oder sollte / kann ich diese Verletzung ignorieren?
Ich stimme FxCop und den meisten anderen Antworten hier zu: fangen Sie System.Exception niemals ab, es sei denn, es befindet sich auf der höchsten Ebene in Ihrer Anwendung, um unerwartete (und somit fatale) Ausnahmen zu protokollieren und dann bombardiere die Anwendung. Auch diese Frage, die im Grunde ungefähr gleich ist Ding.
Einige andere gültige Ausnahmen könnten sein:
ExpectedExceptionAttribute benötigt. Ich stimme den anderen Antworten zu, dass catch (Exception ex) in Ordnung ist, wenn Sie entweder
Es gibt eine weitere Situation, die mir in den Sinn kommt, wo es Sinn machen könnte: Wenn unbeaufsichtigter Code geschrieben wird (zB ein Systemdienst), kann es sinnvoll sein, das Programm weiterlaufen zu lassen wenn gut definierte) Unteraufgabe fehlschlägt, aus welchem Grund auch immer. Natürlich muss darauf geachtet werden, dass der Grund für das Problem protokolliert wird und (vielleicht) die Aufgabe nach einiger Zeit erneut versucht wird.
Wenn Sie Bibliothek (Framework) schreiben, dann ist FxCop 100% richtig.
Sie fangen Ausnahmen - was es bedeutet? dass du weißt, warum sie geworfen haben. Sind Sie sicher, dass Sie alle möglichen Gründe kennen?
Wenn Sie nur eine Anwendung schreiben, sind Variationen möglich. Zum Beispiel, wenn Sie alle nicht behandelten Ausnahmen für die Protokollierung abfangen.
Graue Fläche ...
In einer idealen Welt würden Sie immer eine explizite Ausnahme einfangen, weil diese in der Theorie die einzige Art sind, mit der Sie vernünftig umgehen können - alles andere sollte bis zu einem Top-Level-Handler reichen.
Das Problem ist, dass wir nicht unbedingt in einer idealen Welt leben und vielleicht einen generischen Handler verwenden möchten, um zusätzliche Informationen über die generische Ausnahme (Parameter usw.) in die Ausnahme zu häufen und / oder eine zusätzliche Protokollierung durchzuführen Ausnahme sichern Sie den Baum und auf jeden Fall - auf der entsprechenden Ebene - um Dinge so zu arrangieren, dass unsere Endbenutzer keine rohen Ausnahmen in der Benutzeroberfläche sehen. Der Gegenentwurf dazu wäre, dass neue Fehler auf einer niedrigen Ebene auftreten (anstatt zu Ihrem App-Level-Handler zu gelangen), dann fügen Sie eine ausnahmespezifische Behandlung hinzu, die Ihre Erfassung für Sie übernehmen kann - aber es kann zu Bereitstellungsproblemen kommen eine Lösung, die einen generischen Fall in Code-Bits einbezieht, die aus irgendeinem Grund ein wenig anfälliger für unbehandelte Ausnahmen sind, die man vielleicht mag.
Wenn ich es wäre, würde ich wahrscheinlich die Flagge auf einer Assembly-Basis betrachten ...
ps. Ich gehe davon aus, dass Sie zu keinem Zeitpunkt einen Handler haben, der nur die Ausnahme verschluckt und der App erlaubt, weiterzumachen.
Sie sollen Ausnahmen verschlucken, mit denen Sie umgehen können. Wenn Sie die Ausnahme abfangen und nicht abwerfen (entweder direkt oder in eine bestimmte Ausnahme eingeschlossen), kennen Sie die Besonderheiten der Ausnahme im Zusammenhang mit der Anwendung. Da Exception alles sein kann, ist es unwahrscheinlich, dass Sie damit umgehen können.
Wenn Sie nur die Ausnahme protokollieren, ist das keine große Sache, loggen Sie sie einfach ein und werfen Sie sie auf eine äußere Ebene, die behandelt oder abgefangen werden kann.
Wenn der Code im Block nur eine IOException auslösen soll, warum möchten Sie dann auch System.Exception abfangen?
Dann ist der Konformitätsgrad der FxCop-Richtlinien, den Sie erreichen wollen, eine Ihrer Wahlmöglichkeiten. Ich würde nichts Schlimmes darin sehen, jede Ausnahme auf der höchstmöglichen Ebene zu erfassen und alle möglichen Informationen zu protokollieren, zum Beispiel.
Sie sollten nur Ausnahmen abfangen, an denen Sie etwas ändern können. Andernfalls sollte die Ausnahme bis zum Aufrufer weitergegeben werden, oder wenn beispielsweise in einer Gui-Anwendung die Ausnahmen von einem generischen catch all-Handler behandelt und dann protokolliert werden sollen. Siehe: UnhandledException Also fangen Sie nicht, es sei denn, Sie beabsichtigten, etwas damit zu tun .. zugegebenermaßen könnte das einfach den Fehler protokollieren.
Bearbeiten Sehen Sie sich auch Application.ThreadException
anWas sagt FxCopy über die spezifische Verletzung? Wenn Sie nur Informationen über eine Ausnahme protokollieren möchten, und diese dann erneut ausführen, ist dies vollkommen korrekt. Es gibt jedoch andere Möglichkeiten, dies zu tun. Wenn Sie es jedoch erneut aufrufen, stellen Sie sicher, dass Sie nur Folgendes verwenden:
%Vor%und nicht
%Vor%Vielleicht ist das das Problem?
Tags und Links c# exception-handling