Auslösen von Ausnahmen
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.
Berichten Sie Ausführungsfehler durch das Auslösen von Ausnahmen. Wenn ein Member seine vorgesehene Aufgabe nicht erfolgreich ausführen kann, muss dies als Ausführungsfehler betrachtet und eine Ausnahme ausgelöst werden.
Möglicherweise empfiehlt es sich, den Prozess durch den Aufruf von System.Environment.FailFast(System.String) (ein Feature von .NET Framework, Version 2.0) zu beenden, statt eine Ausnahme auszulösen, wenn eine Situation im Code auftritt, in der die Fortsetzung der Ausführung ein Risiko darstellt.
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);
}
}
}
}
public ref class Doer
{
public:
// Method that can potential throw exceptions often.
static void ProcessMessage(String^ message)
{
if (message == nullptr)
{
throw gcnew ArgumentNullException("message");
}
}
// Other methods...
};
public ref class Tester
{
public:
static void TesterDoer(ICollection<String^>^ messages)
{
for each (String^ message in messages)
{
// Test to ensure that the call
// won't cause the exception.
if (message != nullptr)
{
Doer::ProcessMessage(message);
}
}
}
};
Weitere Informationen über Entwurfsmuster, die die Anzahl ausgelöster Ausnahmen reduzieren können, finden Sie unter Ausnahmen und Leistung.
Berücksichtigen Sie die Auswirkungen des Auslösens von Ausnahmen auf die Leistung.
Dokumentieren Sie alle von öffentlich aufrufbaren Membern aufgrund einer Verletzung eines Membervertrags (und nicht aufgrund eines Systemausfalls) ausgelösten Ausnahmen, und behandeln Sie sie als Bestandteil des Vertrags. Ausnahmen, die ein Bestandteil des Vertrags sind, sollten nicht in neueren Versionen geändert werden.
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)
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 unter „Framework-Entwurfs-Richtlinien: Idiome, Konventionen und Muster für wiederverwendbare .NET-Bibliotheken von Krzysztof Cwalina“ book und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.
Siehe auch
Konzepte
Auswählen des richtigen Typs der auszulösenden Ausnahme