Verwenden von Standardausnahmetypen

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.

In diesem Abschnitt werden die vom Framework bereitgestellten Standardausnahmen und Details ihrer Nutzung beschrieben. Die Liste ist keineswegs vollständig. Informationen zur Nutzung anderer Ausnahmetypen im Framework finden Sie in der Referenzdokumentation zu .NET Framework.

Ausnahme und SystemException

System.Exception oder System.SystemException NICHT auslösen.

System.Exception oder System.SystemException in Frameworkcode NICHT abfangen, es sei denn, Sie beabsichtigen ein erneutes Auslösen.

❌ Abfangen von System.Exception oder System.SystemException VERMEIDEN, außer in Ausnahmehandlern auf oberster Ebene.

ApplicationException

ApplicationException NICHT auslösen oder davon ableiten.

InvalidOperationException

✔️ InvalidOperationException AUSLÖSEN, wenn sich das Objekt in einem unangemessenen Zustand befindet.

ArgumentException, ArgumentNullException und ArgumentOutOfRangeException

✔️ ArgumentException oder einen der Untertypen AUSLÖSEN, wenn ungültige Argumente an einen Member übergeben werden. Bevorzugen Sie möglichst den am stärksten abgeleiteten Ausnahmetyp.

✔️ Die ParamName-Eigenschaft FESTLEGEN, wenn Sie eine der Unterklassen von ArgumentException auslösen.

Diese Eigenschaft stellt den Namen des Parameters dar, der das Auslösen der Ausnahme verursacht hat. Beachten Sie, dass die Eigenschaft mithilfe einer der Konstruktorüberladungen festgelegt werden kann.

✔️ value für den Namen des impliziten Wertparameters von Eigenschaftensettern VERWENDEN.

NullReferenceException, IndexOutOfRangeException und AccessViolationException

❌ NICHT zulassen, dass öffentlich aufrufbare APIs NullReferenceException, AccessViolationException oder IndexOutOfRangeException explizit oder implizit auslösen. Diese Ausnahmen sind reserviert, werden von der Ausführungs-Engine ausgelöst und weisen in den meisten Fällen auf einen Fehler hin.

Führen Sie die Argumentüberprüfung durch, um das Auslösen dieser Ausnahmen zu vermeiden. Durch das Auslösen dieser Ausnahmen werden Implementierungsdetails Ihrer Methode verfügbar gemacht, die sich im Laufe der Zeit ändern können.

StackOverflowException

StackOverflowException NICHT explizit auslösen. Die Ausnahme darf explizit nur von der CLR ausgelöst werden.

StackOverflowException NICHT abfangen.

Es ist fast unmöglich, verwalteten Code zu schreiben, der angesichts beliebiger Stapelüberläufe konsistent bleibt. Die nicht verwalteten Teile der CLR bleiben konsistent, indem Tests mithilfe von Tests Stapelüberläufe an klar definierte Stellen verschoben werden, anstatt sich aus beliebigen Stapelüberläufen zurückzuziehen.

OutOfMemoryException

OutOfMemoryException NICHT explizit auslösen. Diese Ausnahme wird nur von der CLR-Infrastruktur ausgelöst.

ComException, SEHException und ExecutionEngineException

COMException, ExecutionEngineException und SEHException NICHT explizit auslösen. Diese Ausnahmen dürfen nur von der CLR-Infrastruktur ausgelöst werden.

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.

Weitere Informationen