Auslösen von Ausnahmen
Hinweis
Diese Inhalte wurden mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines nachgedruckt: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Diese Ausgabe wurde 2008 veröffentlicht, und das Buch wurde seitdem in der dritten Ausgabe vollständig überarbeitet. Einige der Informationen auf dieser Seite sind möglicherweise veraltet.
Die in diesem Abschnitt beschriebenen Richtlinien zum Auslösen von Ausnahmen erfordern eine gute Definition der Bedeutung von Ausführungsfehlern. Ein Ausführungsfehler tritt auf, wenn ein Member nicht die Aufgaben ausführen kann, die er ausführen soll (was der Membername beinhaltet). Wenn die OpenFile-Methode z. B. kein Dateiöffnungshandle an den Aufrufer zurückgeben kann, wird dies als Ausführungsfehler betrachtet.
Die meisten Entwickler haben sich angewöhnt, Ausnahmen für Verwendungsfehler wie Division durch null (0) oder NULL-Verweise zu verwenden. Im Framework werden Ausnahmen für alle Fehlerbedingungen einschließlich Ausführungsfehlern verwendet.
❌ Geben Sie KEINE Fehlercodes zurück.
Ausnahmen sind die primäre Methode, Fehler in Frameworks zu melden.
✔️ MELDEN Sie Ausführungsfehler durch Auslösen von Ausnahmen.
✔️ ERWÄGEN Sie, den Prozess durch Aufrufen von System.Environment.FailFast (.NET Framework 2.0-Feature) zu beenden, anstatt eine Ausnahme auszulösen, wenn Ihr Code eine Situation feststellt, in der eine weitere Ausführung unsicher ist.
❌ Verwenden Sie nach Möglichkeit KEINE Ausnahmen für die normale Ablaufsteuerung.
Mit Ausnahme von Systemfehlern und Vorgängen mit potenziellen Racebedingungen sollten Frameworkdesigner APIs entwerfen, damit Benutzer Code schreiben können, der keine Ausnahmen auslöst. Sie können z. B. eine Möglichkeit bieten, vor dem Aufrufen eines Members Vorbedingungen zu überprüfen, damit Benutzer Code schreiben können, der keine Ausnahmen auslöst.
Der Member, der zum Überprüfen der Vorbedingungen eines anderen Members verwendet wird, wird häufig als Tester bezeichnet, und der Member, der die Arbeit tatsächlich erledigt, als Macher.
In manchen Fällen kann das Tester-Macher-Muster einen unzulässigen Leistungsmehraufwand verursachen. In solchen Fällen sollte das so genannte Versuch-Analyse-Muster berücksichtigt werden (weitere Informationen finden Sie unter Ausnahmen und Leistung).
✔️ BERÜCKSICHTIGEN Sie die Auswirkungen des Auslösens von Ausnahmen auf die Leistung. Auslöseraten oberhalb 100 pro Sekunde wirken sich wahrscheinlich deutlich auf die Leistung der meisten Anwendungen aus.
✔️ DOKUMENTIEREN Sie alle Ausnahmen, die von öffentlich aufrufbaren Membern aufgrund eines Verstoßes gegen den Membervertrag (statt eines Systemfehlers) ausgelöst werden, und behandeln Sie sie als Teil Ihres Vertrags.
Ausnahmen, die Teil des Vertrags sind, sollten sich nicht von einer Version zur nächsten ändern (d. h., der Ausnahmetyp sollte nicht geändert und keine neuen Ausnahmen hinzugefügt werden).
❌ Verwenden Sie KEINE öffentlichen Member, die aufgrund einer bestimmten Option Ausnahmen auslösen können oder nicht.
❌ Verwenden Sie KEINE öffentlichen Member, die Ausnahmen als Rückgabewert oder einen out-Parameter zurückgeben.
Ausnahmen aus öffentlichen APIs zurückzugeben, anstatt sie auszulösen, macht viele Vorteile der ausnahmebasierten Fehlerberichterstattung zunichte.
✔️ ERWÄGEN Sie die Verwendung von Methoden zum Generieren von Ausnahmen.
Häufig wird die gleiche Ausnahme an unterschiedlichen Stellen ausgelöst. Um eine Codeüberfrachtung zu vermeiden, verwenden Sie Hilfsmethoden, die Ausnahmen erstellen und ihre Eigenschaften initialisieren.
Außerdem werden Member, die Ausnahmen auslösen, nicht inline positioniert. Wenn Sie die Auslösungsanweisung innerhalb des Generators verschieben, kann es möglich sein, den Member inline zu positionieren.
❌ Lösen Sie KEINE Ausnahmen aus Ausnahmefilterblöcken heraus aus.
Wenn ein Ausnahmefilter eine Ausnahme auslöst, wird die Ausnahme von der CLR abgefangen, und der Filter gibt FALSE zurück. Dieses Verhalten kann nicht vom ausgeführten Filter unterschieden werden, der explizit FALSE zurückgibt, und ist daher sehr schwer zu debuggen.
❌ VERMEIDEN Sie das explizite Auslösen von Ausnahmen aus Finally-Blöcken heraus. Aus aufrufenden, auslösenden Methoden resultierende implizit ausgelöste Ausnahmen sind zulässig.
Teile ©2005, 2009 Microsoft Corporation. Alle Rechte vorbehalten.
Nachdruck mit Genehmigung von Pearson Education, Inc aus Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Oktober 2008 durch Addison-Wesley Professional als Teil der Microsoft Windows Development Series.