Freigeben über

Ausnahmen und Leistung

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.

Ein häufiges Problem im Zusammenhang mit Ausnahmen besteht darin, dass die Leistung der Implementierung inakzeptabel ist, wenn Ausnahmen für Code verwendet werden, der routinemäßig fehlschlägt. 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, während die Ausnahmerichtlinien strikt eingehalten werden, die die Verwendung von Fehlercodes nicht zulassen. Zwei in diesem Abschnitt beschriebene Muster schlagen Möglichkeiten vor, dies zu tun.

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

Um die Leistung zu verbessern, ist es möglich, entweder das Tester-Doer Pattern oder das Try-Parse Pattern zu verwenden, das in den nächsten beiden Abschnitten beschrieben wird.

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 ein Leistungsproblem in Szenarien sein, in denen erwartet wird, dass der Methodenaufruf häufig fehlschlägt. Eine der Möglichkeiten zur Behebung des Problems besteht darin, zu testen, ob die Sammlung schreibbar ist, bevor Sie versuchen, einen Wert hinzuzufügen.

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

Das Element, das zum Testen einer Bedingung verwendet wird, die in unserem Beispiel die Eigenschaft IsReadOnlyist, 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 leistungsempfindlichen APIs sollte ein noch schnelleres Muster als das im vorherigen Abschnitt beschriebene Tester-Doer 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 das Parsen einer Zeichenfolge fehlschlägt. Außerdem wird eine entsprechende TryParse Methode definiert, die versucht, zu analysieren, aber "false" zurückgibt, wenn die Analyse nicht erfolgreich ist und das Ergebnis einer erfolgreichen Analyse mit einem out Parameter zurückgibt.

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

Bei verwendung dieses Musters ist es wichtig, die Try-Funktionalität streng zu 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 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.

Siehe auch