Uitzonderingen en prestaties

Een veelvoorkomend probleem met betrekking tot uitzonderingen is dat als uitzonderingen worden gebruikt voor code die regelmatig mislukt, de prestaties van de implementatie onaanvaardbaar zijn. Dit is ons inziens een terechte bezorgdheid. Wanneer een lid een uitzondering opwerpt, kan de prestatie vele malen langzamer worden. Het is echter mogelijk om goede prestaties te bereiken terwijl u strikt voldoet aan de uitzonderingsrichtlijnen die het gebruik van foutcodes weigeren. Twee patronen die in deze sectie worden beschreven, stellen manieren voor om dit te doen.

❌ GEBRUIK GEEN foutcodes vanwege zorgen dat uitzonderingen een negatieve invloed kunnen hebben op de prestaties.

Om de prestaties te verbeteren, is het mogelijk om het Tester-Doer Patroon of het Try-Parse Patroon te gebruiken, zoals beschreven in de volgende twee secties.

Tester-Doer patroon

Soms kunnen de prestaties van een lid dat een uitzondering werpt worden verbeterd door het lid in twee delen op te splitsen. Laten we eens kijken naar de Add methode van de ICollection<T> interface.

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

De methode Add geeft een foutmelding als de verzameling alleen-lezen is. Dit kan een prestatieprobleem zijn in scenario's waarin de methode-aanroep naar verwachting vaak mislukt. Een van de manieren om het probleem te verhelpen, is om te testen of de verzameling beschrijfbaar is voordat u een waarde probeert toe te voegen.

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

Het lid dat wordt gebruikt om een voorwaarde te testen, die in ons voorbeeld de eigenschap IsReadOnlyis, wordt de tester genoemd. Het lid dat wordt gebruikt om een bewerking uit te voeren die mogelijk uitzonderingen opwerpt, de Add-methode in ons voorbeeld, wordt de uitvoerder genoemd.

✔️ HOUD REKENING MET het Tester-Doer patroon voor leden die uitzonderingen kunnen genereren in veelvoorkomende scenario's om prestatieproblemen met betrekking tot uitzonderingen te voorkomen.

Try-Parse patroon

Voor uiterst prestatiegevoelige API's moet een nog sneller patroon worden gebruikt dan het Tester-Doer patroon dat in de vorige sectie wordt beschreven. Het patroon vraagt om de lidnaam aan te passen zodat een goed gedefinieerde testcase deel uitmaakt van de semantiek van het lid. Definieert bijvoorbeeld DateTime een Parse methode die een uitzondering genereert als het parseren van een tekenreeks mislukt. Het definieert ook een bijbehorende TryParse methode die probeert te parseren, maar retourneert onwaar als parseren mislukt en retourneert het resultaat van een geslaagde parsering met behulp van een out parameter.

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

Wanneer u dit patroon gebruikt, is het belangrijk om de try-functionaliteit strikt te definiëren. Als het lid om een andere reden mislukt dan de goed gedefinieerde poging, moet het lid nog steeds een overeenkomstige uitzondering opwerpen.

✔️ HOUD REKENING MET het Try-Parse patroon voor leden die uitzonderingen kunnen genereren in veelvoorkomende scenario's om prestatieproblemen met betrekking tot uitzonderingen te voorkomen.

✔️ Gebruik het voorvoegsel Try en booleaanse retourtype voor methoden die dit patroon implementeren.

✔️ GEEF een lid dat uitzonderingen gooit op voor elk lid met het Try-Parse patroon.

© Gedeelten 2005, 2009 Microsoft Corporation. Alle rechten voorbehouden.

Herdrukt door toestemming van Pearson Education, Inc. van Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, gepubliceerd 22 oktober 2008 door Addison-Wesley Professional als onderdeel van de Microsoft Windows Development Series.

Zie ook

• Ontwerprichtlijnen voor frameworks
• Ontwerprichtlijnen voor uitzonderingen