Also in meinem Programm habe ich Teile, wo ich versuche, Blöcke wie diese zu fangen
%Vor%Natürlich könnte ich wahrscheinlich überprüfen, ob die Zeichenfolge gültige Pfad (Regex) ist, dann würde ich überprüfen, ob das Verzeichnis existiert, dann konnte ich verschiedene Ausnahmen abfangen, um zu sehen, warum meine Routine fehlgeschlagen ist und weitere Informationen geben ... Aber in meinem Programm ist es nicht wirklich notwendig. Jetzt muss ich wirklich wissen, ob das akzeptabel ist und was ein Profi dazu sagen würde. Vielen Dank für Ihre Aufmerksamkeit.
Wenn es Ihnen wirklich egal ist, warum es fehlgeschlagen ist und Ihr Programm vernünftigerweise nichts tun kann, um es wiederherzustellen, dann ist es in Ordnung, so etwas zu tun; Ich würde eher etwas so beibehalten als Code, der 3 try / catch-Blöcke verwendet, um dasselbe zu tun, aber ohne zusätzlichen Wert hinzuzufügen. Ich mag den Namen der Ausnahme, die kommuniziert, es ist nicht wichtig, das ist besser als eine Variable namens ex .
Einige Vorschläge jedoch:
Wenn Sie "abfangen und ignorieren" möchten, sollten Sie genauer angeben, welche Exception-Typen ignoriert werden dürfen . Wenn Sie wissen, dass Sie FileNotFoundException oder eine beliebige Klasse von IOException ignorieren können, fangen Sie einfach damit auf.
Wenn Sie eine generische Ausnahme abfangen möchten, sollten Sie die Ausnahme irgendwo protokollieren . Ihr aktueller Ansatz könnte ein Wartungsalarm sein, wenn in Ihrem try-Block ein logischer Defekt vorhanden ist. Nehmen wir zum Beispiel an, dass Sie einen Fehler nach dem anderen in Bezug auf einen Array-Index codieren ... Ihr aktueller Code wird das schlucken und keinen Hinweis darauf geben, dass etwas Wichtigeres als "Verzeichnis existiert nicht" aufgetreten ist.
Wenn eine Mainline, erwarteter, alltäglicher Fall ist, dass der Pfad nicht existiert, dann schreibe Mainline-Code, der prüft, ob der Pfad existiert. Wenn ein unerwarteter, bizarrer, außergewöhnlicher Umstand darin besteht, dass die Datei existiert, aber von einem anderen Benutzer gesperrt wurde, schreiben Sie einen Ausnahmebehandler, der diese Ausnahme behandelt.
Sie sollten keine Ausnahmen für die Ablaufsteuerung verwenden, da dies die Leistung beeinträchtigt und Ausnahmen nicht für diesen Zweck vorgesehen sind. Stattdessen sollten Sie die Exists -Eigenschaft testen, um zu überprüfen, ob das Verzeichnis vorhanden ist
Es hängt wirklich davon ab, wie Sie mit diesen Fehlerbedingungen umgehen.
Wenn Sie auf jeden Fall die Exception beenden und nur die Exception drucken, und Ihre Benutzer mit dem Lesen und Verstehen dieser Art von Ausgabe vertraut sind, ist das völlig in Ordnung, und Sie würden Zeit und Code verschwenden, um damit umzugehen genauer gesagt.
Auf der anderen Seite, wenn Sie eine Reihe von if-Tests in Ihrem Code zur Ausnahmebehandlung haben, um verschiedene Dinge basierend darauf zu tun, welche Ausnahme aufgetreten ist, dann ist das ziemlich deutliche Beweis, dass Sie verschiedene Ausnahmen anders behandeln sollten.
Und wenn Ihre Benutzer keine "Techies" sind und mehr hilfreiche Fehlermeldungen als Ausnahme-Dumps benötigen, sollten Sie selbst mehr benutzerdefinierte Fehlerbehandlung durchführen. Selbst wenn sie Techies sind, würden sie wahrscheinlich klarere Fehlermeldungen schätzen.
Es gibt keine richtige Antwort. Es hängt wirklich von Ihrer Zielbenutzererfahrung ab.
Ich würde einen Exception-Handler vom Typ Catch-All nicht empfehlen. Stattdessen sollten Sie DirectoryInfo und die Arten von Ausnahmen suchen, die es auslösen kann. Dann sollten Sie versuchen, so viele wie möglich zu vermeiden, bevor Sie den Konstruktor aufrufen und nur die Ausnahmen abfangen, die Sie erwarten. Also würde mein Code wie folgt aussehen:
Sie sollten die Validierung wann immer möglich durchführen. Ausnahmen sind teuer und sollten möglichst vermieden werden.
Das Ausführen von Überprüfungen für den Pfad und andere Validierungen beseitigt nicht notwendigerweise die Notwendigkeit von Ausnahmebehandlungs- und Testblocks. Ausnahmen treten immer auf (Verzeichnis existiert nicht, Netzwerk ist nicht verbunden) es sind unerwartete, unvorhersehbare Ausnahmen, die try / catch-Blöcke behandeln sollen.
Ich bin auch schuld an dieser Art von Lazy Coding, normalerweise, wenn es darum geht, die "heißen" Funktionen schnell zu ändern. Das Problem ist, dass die Bereinigung des Lazy-Codes eine niedrige Priorität erhält, wenn man den neuen Stapel von unvermeidlich "heißen" Feature-Requests in Betracht zieht, was bedeutet, dass sich diese Art von Lazy-Code akkumuliert. Diese faulen Exception-Catch-Blöcke führen dann dazu, wirklich unerwartete Probleme zu verschlucken und plötzlich hat sich der Anwendungszustand auf unerwartete Weise verändert. Ich diszipliniere mich selbst, dies nicht zu tun, weil das Schreiben von Lazy Code wie das Verwenden einer Kreditkarte ist. Sie können jetzt Dinge liefern, die Sie später hätten liefern müssen, aber es ist die Kombination, die Sie bekommt, wenn es Zeit ist, es zurückzuzahlen.
Auch wenn Sie selbst überprüfen (es ist ein gültiger Pfad, der Pfad existiert, Sie dürfen darauf zugreifen, er ist nicht gesperrt, usw.), Sie müssen immer noch die Ausnahmebehandlung haben. Obwohl es unwahrscheinlich erscheint, gibt es keinen Grund, dass sich die Bedingungen nicht von dem Zeitpunkt an ändern, an dem Sie sie überprüfen, bis zu dem Zeitpunkt, zu dem Sie tatsächlich auf den Pfad zugreifen.
Wenn Sie die Ausnahmebehandlung von Anfang an benötigen, warum sollten Sie redundante Überprüfungen durchführen? Das OS wird sie sowieso alle wieder tun müssen, und die Chancen stehen gut, dass sie es sowieso nicht schaffen.
Sorgen Sie sich nicht um die Kosten von Ausnahmen. Im Vergleich zu den Kosten für die Ein- / Ausgabe sind die Kosten für eine Ausnahme vernachlässigbar.
Das heißt, es ist nicht gut, alle Ausnahmen zu erfassen, ohne etwas zu tun. Wie Seth sagte, fange entweder nur IOException oder melde die Ausnahme. Wenn Sie dies nicht tun, wird dieser Teil des Codes wirklich schwer zu debuggen sein.
Tags und Links c# coding-style