Freigeben über


Auslösen von Ausnahmen

Aktualisiert: November 2007

Ausnahmen werden ausgelöst, wenn ein Member die vorgesehene Aufgabe nicht erfolgreich ausführen kann. Dies wird als fehlgeschlagene Ausführung bezeichnet. Wenn z. B. die Connect-Methode keine Verbindung mit einem bestimmten Remoteendpunkt herstellen kann, ist dies ein Ausführungsfehler, und es wird eine Ausnahme ausgelöst.

Anhand der folgenden Richtlinien können Sie sicherstellen, dass Ausnahmen ausgelöst werden, wenn dies sinnvoll ist.

Geben Sie keine Fehlercodes zurück. Ausnahmen sind die primären Mittel zum Berichten von Fehlern in Frameworks.

In Entwurfsrichtlinien für Ausnahmen werden viele der Vorteile erörtert, die die Verwendung von Ausnahmen bietet.

Verwenden Sie nach Möglichkeit Ausnahmen nicht für die normale Ablaufsteuerung. Abgesehen von Systemausfällen und Operationen mit potenziellen Racebedingungen sollten Framework-Entwickler APIs so entwerfen, dass Benutzer Code schreiben können, der keine Ausnahmen auslöst. Sie können beispielsweise ein Verfahren bereitstellen, um vor dem Aufruf eines Members Vorbedingungen zu überprüfen, sodass die Benutzer Code schreiben können, der keine Ausnahmen auslöst.

Im folgenden Codebeispiel wird das Testen zum Verhindern von Ausnahmen veranschaulicht, die ausgelöst werden, wenn eine Meldungszeichenfolge null (Nothing in Visual Basic) ist.

Public Class Doer

    ' Method that can potential throw exceptions often.
    Public Shared Sub ProcessMessage(ByVal message As String)
        If (message = Nothing) Then
            Throw New ArgumentNullException("message")
        End If
    End Sub

    ' Other methods...
End Class

Public Class Tester

    Public Shared Sub TesterDoer(ByVal messages As ICollection(Of String))
        For Each message As String In messages
            ' Test to ensure that the call 
            ' won't cause the exception.
            If (Not (message) Is Nothing) Then
                Doer.ProcessMessage(message)
            End If
        Next
    End Sub
End Class
public class Doer
{
    // Method that can potential throw exceptions often.
    public static void ProcessMessage(string message)
    {
        if (message == null)
        {
            throw new ArgumentNullException("message");
        }
    }
    // Other methods...
}

public class Tester
{
    public static void TesterDoer(ICollection<string> messages)
    {
        foreach (string message in messages)
        {
            // Test to ensure that the call
            // won't cause the exception.
            if (message != null)
            {
                Doer.ProcessMessage(message);
            }
        }
    }
}

Weitere Informationen über Entwurfsmuster, die die Anzahl ausgelöster Ausnahmen reduzieren können, finden Sie unter Ausnahmen und Leistung.

Verwenden Sie keine öffentlichen Member, die je nach einer bestimmten Option eine Ausnahme oder keine Ausnahme auslösen können.

Definieren Sie z. B. keine Member wie den folgenden:

Private Function ParseUri(ByVal uriValue As String, ByVal throwOnError As Boolean) As Uri
Uri ParseUri(string uriValue, bool throwOnError)

Verwenden Sie keine öffentlichen Member, die Ausnahmen als Rückgabewert oder als out-Parameter zurückgeben.

Diese Richtlinie gilt für öffentlich sichtbare Member. Es ist zulässig, eine private Hilfsmethode zum Erstellen und Initialisieren von Ausnahmen zu verwenden.

Verwenden Sie Methoden zum Generieren von Ausnahmen. Häufig wird dieselbe Ausnahmen an verschiedenen Stellen ausgelöst. Um zu umfangreichen Code zu vermeiden, verwenden Sie Hilfsmethoden, die Ausnahmen erstellen und ihre Eigenschaften initialisieren.

Die Hilfsmethode darf keine Ausnahme auslösen. Andernfalls gibt die Stapelüberwachung die Aufrufliste nicht genau wieder, die die Ausnahme ausgelöst hat.

Lösen Sie keine Ausnahmen aus Ausnahmefilterblöcken aus. Wenn ein Ausnahmefilter eine Ausnahme auslöst, wird die Ausnahme durch die Common Language Runtime (CLR) abgefangen, und der Filter gibt false zurück. Dieses Verhalten kann nicht von der Ausführung des Filters und der expliziten Rückgabe von false durch den Filter unterschieden werden und ist daher sehr schwierig zu debuggen.

Einige Sprachen, z. B. C#, unterstützen keine Ausnahmefilter.

Lösen Sie Ausnahmen nicht explizit in finally-Blöcken aus. Implizit ausgelöste Ausnahmen, die durch den Aufruf Ausnahmen auslösender Methoden verursacht werden, sind zulässig.

Copyright für einzelne Teile 2005 Microsoft Corporation. Alle Rechte vorbehalten.

Copyright für einzelne Teile Addison-Wesley Corporation. Alle Rechte vorbehalten.

Weitere Informationen zu Entwurfsrichtlinien finden Sie im Buch "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" von Krzysztof Cwalina und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.

Siehe auch

Konzepte

Auswählen des richtigen Typs der auszulösenden Ausnahme

Weitere Ressourcen

Entwurfsrichtlinien zum Entwickeln von Klassenbibliotheken

Entwurfsrichtlinien für Ausnahmen