Dies ist die eigentliche Quelle für .NET System.Exception.ToString :
Abgesehen von der schlichten Hässlichkeit kann man bemerken, dass für alle inneren Ausnahmen der private, nicht-virtuelle ToString genannt wird. Mit anderen Worten, wenn Sie ToString in Ihrer Exception überladen, wird es nicht aufgerufen, wenn Ihre Exception verschachtelt ist . Oh, festhalten, stellt sich heraus, eingebaute Ausnahmen haben die gleichen Probleme, z.B. System.IO.FileNotFoundException gibt den Pfad der Datei aus - sie ist kein Teil der Nachricht:
Wenn Sie jedoch eine Instanz umbrechen ... gehen diese Informationen verloren, es sei denn, Sie durchlaufen selbst den Exception-Baum und ermitteln den Typ der Exceptions oder rufen ToString selbst auf und führen ein banales Parsen durch.
Das ist eine lästige Unannehmlichkeit, die dazu führt, dass Protokoll- / Schreibfehler-Dialoge entweder Informationen verlieren oder fehleranfällig sind. Interessanterweise Mono macht es richtig .
>Gibt es irgendwelche versteckten Weisheiten in der .NET-Version?
BEARBEITEN: das ist keine meinungsbezogene Frage. Während ich diese Designauswahl als ärgerlich empfinde, würde ich gerne die Vorteile dieses Ansatzes kennenlernen. Sie zu kennen, kann bei der Entwicklung neuer Lösungen von Vorteil sein.
Exception.ToString() sollte Benutzern nicht angezeigt werden. Es ist etwas, das Entwicklern vielleicht in einer Protokolldatei präsentiert werden sollte.
Die Standardimplementierung von ToString () macht normalerweise das "Richtige". Beachten Sie, dass es geschachtelte Ausnahmen und mehrere Ausnahmen (wie AggregateException oder SqlException ) und sogar Ausnahmen über eine Remoting-Grenze hinweg behandelt. Versuchen Sie, bei der Deserialisierung von XML mit dem XML-Serializer einen Fehler zu erhalten, und Sie werden wirklich schätzen, wie viele Informationen Sie erhalten - normalerweise genug, um direkt auf die Ursache der Ausnahme zu verweisen.
Wenn Sie möchten, dass etwas Bestimmtes angezeigt wird, sollten Sie Microsoft auf dieses Problem hinweisen. Insbesondere werden Sie sie wahrscheinlich nicht dazu bringen, Ihren überschriebenen ToString einfach aufzurufen. Klar, das will ich nicht. Wenn es jedoch etwas gibt, das Ihr ToString anzeigen wollte, dass ihr nicht angezeigt wird, dann sprechen Sie mit ihnen und sehen Sie, ob es noch einen anderen Weg gibt, oder ob Sie etwas in einer zukünftigen Version tun können.
Meiner Erfahrung nach ist die richtige Entscheidung der Framework-Designer nicht die Angabe der inneren Ausnahmedetails im Aufruf von ToString.
Oft wird das Ergebnis von ToString dem Endbenutzer präsentiert, falls die ausführende Anwendung dem Benutzer keine präziseren Informationen über die Art des Problems und mögliche Lösungen liefern kann.
In diesem Fall kann das Verschachteln interner Ausnahmedetails nicht nur für den Endbenutzer verwirrend sein, sondern auch ein potenzielles Sicherheitsrisiko darstellen. Das oben aufgeführte Beispiel für das Dateinamensproblem ist gut: Ich möchte die Verzeichnisinformationen einer Datei auf meinem Webserver keinem externen Benutzer zugänglich machen, falls die Datei nicht gefunden werden könnte (theoretisch würde die Ausnahme immer bestehen) richtig behandelt werden, um diese Exposition zu verhindern, aber keine Anwendung ist perfekt).
Wo die inneren Ausnahmedetails nützlich werden, ist es, den Anwendungsfehler irgendwo zu protokollieren (Ereignisprotokoll, Datei, Datenbank usw.). In diesem Fall werden Sie höchstwahrscheinlich mehr als nur die ToString-Details benötigen. Die Implikation ist also, dass dieser Protokollierungscode für das Extrahieren der entsprechenden Informationen verantwortlich ist, da Sie für diese Situationen ohnehin Protokollierungscode benötigen.
Ich glaube, Microsoft hat dies früh erkannt, da einer der ersten Anwendungsblöcke, die sie ihrer Enterprise Library hinzufügten, Ausnahmebehandlungsblock , der eine detaillierte Durchsicht und Aufzeichnung aller Ausnahmebedingungsdetails bietet, einschließlich öffentlicher Eigenschaften für die Ausnahmen selbst.