Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hinweis
Dieser Inhalt wird mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines: Konventionen, Idiome und Muster für wiederverwendbare .NET-Bibliotheken, 2. Auflage nachgedruckt. 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.
Richtlinien für das Werfen von Ausnahmen, die in diesem Abschnitt beschrieben werden, erfordern eine präzise Definition der Bedeutung von Ausführungsfehlschlägen. Ausführungsfehler tritt auf, wenn ein Mitglied nicht tun kann, was es tun soll (was der Membername impliziert). Wenn die OpenFile Methode z. B. kein geöffnetes Dateihandle an den Aufrufer zurückgeben kann, gilt sie als Ausführungsfehler.
Die meisten Entwickler sind mit der Verwendung von Ausnahmen für Verwendungsfehler wie Division durch Null oder Nullreferenzen vertraut geworden. Im Framework werden Ausnahmen für alle Fehlerbedingungen verwendet, einschließlich Ausführungsfehlern.
❌ GEBEN SIE KEINE Fehlercodes zurück.
Ausnahmen sind die wichtigsten Methoden zum Melden von Fehlern in Frameworks.
✔️ MELDEN Sie Ausführungsfehler durch Auslösen von Ausnahmen.
✔️ ERWÄGEN Sie, den Prozess durch Aufrufen System.Environment.FailFast des Features .NET Framework 2.0 zu beenden, anstatt eine Ausnahme zu auslösen, wenn im Code eine Situation auftritt, in der sie für die weitere Ausführung unsicher ist.
❌ Verwenden Sie ausnahmen nicht für den normalen Kontrollfluss, falls möglich.
Mit Ausnahme von Systemfehlern und Vorgängen mit potenziellen Racebedingungen sollten Framework-Designer APIs entwerfen, damit Benutzer Code schreiben können, der keine Ausnahmen auslöst. Sie können z. B. vor dem Aufrufen eines Mitglieds eine Möglichkeit zum Überprüfen der Vorbedingungen bereitstellen, damit Benutzer Code schreiben können, der keine Ausnahmen auslöst.
Das Mitglied, das zum Überprüfen der Voraussetzungen eines anderen Mitglieds verwendet wird, wird häufig als Tester bezeichnet, und das Element, das die Arbeit tatsächlich ausführt, wird als Doer bezeichnet.
Es gibt Fälle, in denen das Tester-Doer Muster einen inakzeptablen Leistungsaufwand aufweisen kann. In solchen Fällen sollte das sogenannte Try-Parse Muster berücksichtigt werden (weitere Informationen finden Sie unter Ausnahmen und Leistung ).
✔️ BERÜCKSICHTIGEN Sie die Leistungsauswirkungen des Auslösens von Ausnahmen. Wurfraten über 100 pro Sekunde wirken sich wahrscheinlich spürbar auf die Leistung der meisten Anwendungen aus.
Dokumentieren Sie alle Ausnahmen, die von öffentlich aufrufbaren Mitgliedern aufgrund eines Verstoßes gegen den Vertrag (anstelle eines Systemausfalls) ausgelöst werden, und behandeln Sie sie als Teil Ihres Vertrags.
Ausnahmen, die Teil des Vertrags sind, sollten nicht von einer Version zur nächsten geändert werden (d. h. Ausnahmetyp sollte nicht geändert werden, und neue Ausnahmen sollten nicht 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.
Wenn Ausnahmen von öffentlichen APIs zurückgegeben werden, anstatt sie auszuwerfen, werden viele der Vorteile der ausnahmebasierten Fehlerberichterstattung verhindert.
✔️ ERWÄGEN Sie die Verwendung von Methoden zum Generieren von Ausnahmen.
Es ist üblich, die gleiche Ausnahme an unterschiedlichen Stellen auszuwerfen. Verwenden Sie Hilfsmethoden, die Ausnahmen erstellen und ihre Eigenschaften initialisieren, um Codeblähungen zu vermeiden.
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 unterscheidet sich nicht von der Ausführung des Filters und gibt "false" explizit zurück und ist daher sehr schwierig 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 freundlicher Genehmigung von Pearson Education, Inc., aus dem Buch 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 von Addison-Wesley Professional als Teil der Microsoft Windows Development Series.