warum (wenn überhaupt) ist das eine schlechte Idee?
%Vor%Das wichtige hier ist, dass die Funktion eine Ausnahme vom selben Typ wie die "innere Ausnahme" erzeugt.
Ich denke ... "Oh ... eine Ausnahme ist aufgetreten. Ich kann es hier nicht wirklich handhaben, aber ich kann einige zusätzliche Informationen hinzufügen und erneut werfen. Vielleicht ein anderer Handler, weiter oben im Anruf Kette kann damit umgehen. "
Ein möglicher Fall könnte eine Art SQL-Fehler sein. Ich bin vielleicht nicht in der Lage, die Ausnahme zum Zeitpunkt des Aufrufs zu behandeln, aber ich möchte vielleicht zusätzliche "Kontext" -Informationen hinzufügen, wie "Ich habe dies angerufen und weitergegeben".
Es scheint, als ob es nützlich sein könnte, die Aufrufkette als Ausnahme des Typs, der ursprünglich ausgelöst wurde, im Gegensatz zu "Exception" oder "ApplicationException" zu übergeben. Ich weiß, dass ich meine eigenen benutzerdefinierten Ausnahmeklassen erstellen konnte, aber es scheint, dass es nicht viel hinzufügt, wenn Sie bereits eine spezielle Ausnahme haben.
Natürlich könnte ich mich irren. Es könnte eine sehr nützliche Sache sein ... aber eine kleine Stimme schlägt nicht vor.
----- Bearbeiten -----
Betrachten Sie aus Gründen der Debatte die Auswirkungen der folgenden zwei Funktionen (unter Verwendung des obigen Codes):
Dies ... zu oft gesehen:
%Vor%dagegen ...
%Vor%Das Erstellen eines neuen Ausnahmetyps ist keine gute Option für eine allgemeine -Methode wie diese, da der vorhandene Code nicht auf einen bestimmten Fehler reagieren kann. (Translationsausnahmen an API-Grenzen können jedoch nützlich sein).
Es ist gefährlich, eine neue Ausnahme desselben Typs zu erstellen. Verarbeitet die von Ihnen verwendete CreateInstance Überladung alle Felder von innerException in Ihre neue äußere Ausnahme? Was passiert, wenn ein Exception-Handler, der höher auf dem Stack liegt, von der Analyse der Eigenschaft Message abhängt? Was passiert, wenn der Ausnahmekonstruktor Nebenwirkungen hat?
IMHO, was Sie wirklich tun, ist die Protokollierung, und Sie wären wahrscheinlich besser dran, Logging und einen erneuten Wurf zu tun.
Alle Ausnahmen verfügen über eine Data-Eigenschaft, der Sie zusätzliche Daten hinzufügen können. Es ist nicht notwendig, eine neue Ausnahme zu erstellen. Fangen Sie einfach die bestehende Ausnahme und fügen Sie Ihre Informationen hinzu und wiederholen Sie dann die Ausnahme.
Auf diese Weise bekommen Sie Ihren Kuchen und essen ihn auch. :)
Ich denke, Sie sollten Ihren eigenen benutzerdefinierten Ausnahmetyp erstellen. Welche Art von Informationen werden Sie hinzufügen? Wie bekommt der Fänger der Ausnahme, die er erfährt, zusätzliche Informationen? Wenn Sie einen benutzerdefinierten Typ verwenden, verfügen sie über zusätzliche Eigenschaften / Methoden zum Anzeigen oder Aufrufen.
Es kann in einigen Fällen sinnvoll sein. Wenn Sie MyClass.MyFunction die öffentliche "außerhalb" der Assembly betrachten, was dann passiert, ist eine Blackbox zum Aufrufen von Code. Es kann daher vernünftiger sein, dies als den Punkt zu haben, an dem die Ausnahme so weit geschah, wie der aufrufende Code geht, und der vernünftigste Typ von Ausnahme könnte derselbe Typ sein wie der abgefangene.
Ich wäre jedoch vorsichtig. In den meisten Fällen, in denen dies passierte, hättest du entweder feststellen können, dass die Ausnahme passieren würde, und präventiv geworfen (wenn du werfen willst, je früher, desto besser) oder die Ausnahme, die du geworfen hast, ist nicht t wirklich der richtige Typ (wenn Ihr Code eine Datei nicht findet, die eine FileNotFoundException für Sie ist, aber wenn die Dateien ein Implementierungsdetail sind, dann ist es keine FileNotFoundException für den aufrufenden Code), sonst wird die ursprüngliche Ausnahme gemacht perfekter Sinn und es sollte nur erlaubt sein, mit throw; durchzugehen oder sich neu zu entwickeln.
Also, nicht immer eine schlechte Idee, aber oft genug schlimm, dass es immer eine verdächtige Sache ist, zu sehen.
IMHO, wäre es wahrscheinlich gut, ein paar benutzerdefinierte Ausnahmetypen, mit einer Hierarchie für Ausnahmen, die sagen: "Diese Operation fehlgeschlagen, aber der Systemzustand ist, als ob es nie versucht wurde", ein anderer für Ausnahmen, die sagen " Der Vorgang ist fehlgeschlagen, und der Systemstatus wurde gestört, aber er kann möglicherweise nicht abgewickelt werden "und ein anderer für" Der Vorgang ist fehlgeschlagen und das Abwickeln ist fehlgeschlagen; dem Systemstatus kann nicht vertraut werden. " In einigen Kontexten kann eine Ausnahmeklasse als eine andere erfasst und erneut ausgelöst werden (z. B. wenn eine Operation, die die Wiederherstellung des Systemzustands beenden sollte, fehlschlägt, auch wenn aus der Sicht dieser Operation nichts gestört wurde, das Wiederherstellen des Zustands fehlgeschlagen ist) Wenn eine Operation einen Systemzustand gestört hat, aber ein Catch-Handler den Zustand wiederhergestellt hat, könnte er erneut ausgelöst werden, da ein "Vorgang fehlgeschlagen ist, aber der Systemzustand ungestört ist".
Ich finde es nicht gut, zu versuchen, Ausnahme-Instanzen zu erstellen, die blind geworfene Ausnahme-Typen treffen, da die geworfenen Ausnahmen Felder enthalten können, die von Handlern erwartet werden. Ich bin nicht sicher, warum Microsoft Ausnahmen "fast" unveränderlich machte. Es wäre viel schöner, wenn Ausnahmen unabänderlich sein müssten und das Klonen mit jeder Semantik unterstützen würde, die unverrückbar vermittelt wird.
Fangen Sie nur Ausnahmen ab, die Sie behandeln, z. B. möchten Sie nicht, dass eine SqlException von Ihrer Datenschicht auf Ihre Business-Schicht geworfen wird (fangen Sie sie ab, versuchen Sie sie zu handhaben und werfen stattdessen eine DataLayerException oder etwas ähnliches). p>
Tags und Links c# exception-handling