Share via


Ausnahmen und Leistung

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.

Ein häufiges Problem im Zusammenhang mit Ausnahmen ist, dass die Leistung der Implementierung nicht akzeptabel ist, wenn Ausnahmen für Code verwendet werden, bei dem routinemäßig Fehler auftreten. Dieses Bedenken ist berechtigt. Wenn ein Member eine Ausnahme auslöst, kann seine Leistung um einige Größenordnungen reduziert werden. Es ist jedoch möglich, eine gute Leistung zu erzielen und dabei strikt die Ausnahmerichtlinien einzuhalten, die die Verwendung von Fehlercodes nicht zulassen. In den beiden in diesem Abschnitt beschriebenen Mustern werden entsprechende Möglichkeiten vorgeschlagen.

❌ Verwenden Sie Fehlercodes NICHT aus der Befürchtung heraus, Ausnahmen könnten sich negativ auf die Leistung auswirken.

Um die Leistung zu verbessern, können Sie entweder das Tester-Macher-Muster oder das Versuch-Analyse-Muster verwenden, die in den folgenden beiden Abschnitten beschrieben werden.

Tester-Macher-Muster

Manchmal kann die Leistung eines Ausnahmen auslösenden Members verbessert werden, indem der Member in zwei Member unterteilt wird. Sehen wir uns die Add-Methode der ICollection<T>-Schnittstelle an.

ICollection<int> numbers = ...
numbers.Add(1);

Die Methode Add löst eine Ausnahme aus, wenn die Sammlung schreibgeschützt ist. Dies kann in Szenarios, in denen beim Methodenaufruf häufig ein Fehler auftritt, ein Leistungsproblem sein. Eine Möglichkeit, das Problem zu beheben, besteht darin, zu testen, ob die Sammlung beschreibbar ist, bevor versucht wird, einen Wert hinzuzufügen.

ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
    numbers.Add(1);
}

Der zum Testen einer Bedingung verwendete Member, bei dem es sich in unserem Beispiel um die Eigenschaft IsReadOnly handelt, wird als Tester bezeichnet. Der Member, der verwendet wird, um einen potenziell auslösenden Vorgang auszuführen, in unserem Beispiel die Add-Methode, wird als Macher bezeichnet.

✔️ ERWÄGEN Sie das Tester-Macher-Muster für Member, die in häufigen Szenarios Ausnahmen auslösen könnten, um Leistungsprobleme im Zusammenhang mit Ausnahmen zu vermeiden.

Versuch-Analyse-Muster

Bei extrem leistungsabhängigen APIs sollte ein noch schnelleres Muster als das im vorherigen Abschnitt beschriebene Tester-Macher-Muster verwendet werden. Das Muster erfordert, dass der Membername angepasst wird, um einen klar definierten Testfall zu einem Teil der Membersemantik zu machen. Beispielsweise definiert DateTime eine Parse-Methode, die eine Ausnahme auslöst, wenn bei der Analyse einer Zeichenfolge ein Fehler auftritt. Außerdem wird eine entsprechende TryParse-Methode definiert, die versucht, eine Analyse durchzuführen, aber FALSE zurückgibt, wenn die Analyse nicht erfolgreich ist, und das Ergebnis einer erfolgreichen Analyse mithilfe eines out-Parameters zurückgibt.

public struct DateTime
{
    public static DateTime Parse(string dateTime)
    {
        ...
    }
    public static bool TryParse(string dateTime, out DateTime result)
    {
        ...
    }
}

Wenn Sie dieses Muster verwenden, müssen Sie die Versuchsfunktionalität in strikten Begriffen definieren. Wenn bei dem Member aus einem anderen Grund als dem klar definierten Versuch ein Fehler auftritt, muss der Member weiterhin eine entsprechende Ausnahme auslösen.

✔️ ERWÄGEN Sie das Versuch-Analyse-Muster für Member, die in häufigen Szenarios Ausnahmen auslösen könnten, um Leistungsprobleme im Zusammenhang mit Ausnahmen zu vermeiden.

✔️ VERWENDEN Sie das Präfix „Try“ und den booleschen Rückgabetyp für Methoden, die dieses Muster implementieren.

✔️ STELLEN SIE einen Ausnahmen auslösenden Member für jeden Member BEREIT, der das Versuch-Analyse-Muster verwendet.

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