Sdílet prostřednictvím

Výjimky a výkon

Poznámka:

Tento obsah je znovu vytištěn oprávněním Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms a Patterns for Reusable .NET Libraries, 2. vydání. Tato edice byla publikována v roce 2008 a kniha byla od té doby plně upravena ve třetím vydání. Některé informace na této stránce můžou být zastaralé.

Jednou z běžných obav souvisejících s výjimkami je, že pokud se výjimky používají pro kód, který rutinně selhává, bude výkon implementace nepřijatelný. Tato obava je oprávněná. Když člen vyvolá výjimku, jeho výkon může být mnohokrát pomalejší. Je však možné dosáhnout dobrého výkonu a striktně dodržovat pokyny pro výjimky, které nepovolují používání kódů chyb. Dva vzory popsané v této části navrhují způsoby, jak to udělat.

❌ NEPOUŽÍVEJTE kódy chyb kvůli obavám, že výjimky můžou mít negativní vliv na výkon.

Ke zlepšení výkonu je možné použít vzor Tester-Doer nebo Try-Parse vzor popsaný v následujících dvou částech.

vzor Tester-Doer

Někdy je možné zvýšit výkon člena, který vyvolá výjimku, tím, že člen rozdělí na dva. Pojďme se podívat na Add metodu ICollection<T> rozhraní.

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

Metoda Add vyvolá, pokud je kolekce jen pro čtení. Může se jednat o problém s výkonem ve scénářích, kdy se očekává, že volání metody často selže. Jedním ze způsobů, jak tento problém zmírnit, je otestovat, jestli je kolekce před pokusem o přidání hodnoty zapisovatelná.

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

Člen použitý k otestování podmínky, která v našem příkladu je vlastnost IsReadOnly, se označuje jako tester. Člen použitý k provedení potenciálně vyvolávající operaci, Add metoda v našem příkladu, se označuje jako realizátor.

✔️ ZVAŽTE model Tester-Doer pro členy, kteří můžou v běžných scénářích vyvolat výjimky, aby nedocházelo k problémům s výkonem souvisejícím s výjimkami.

vzor Try-Parse

U rozhraní API s extrémně citlivým výkonem by se měl použít ještě rychlejší vzor, než je model Tester-Doer popsaný v předchozí části. Vzor vyžaduje úpravu názvu člena tak, aby byl dobře definovaný testovací případ součástí sémantiky člena. Například DateTime definuje metodu Parse, která vyvolá výjimku, pokud analýza řetězce selže. Definuje také odpovídající TryParse metodu, která se pokusí analyzovat, ale vrátí hodnotu false, pokud je analýza neúspěšná a vrátí výsledek úspěšné analýzy pomocí parametru out .

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

Při použití tohoto vzoru je důležité definovat funkci try v striktních termínech. Pokud člen selže z jakéhokoli jiného důvodu než dobře definovaný pokus, člen musí stále vyvolat odpovídající výjimku.

✔️ ZVAŽTE model Try-Parse pro členy, kteří můžou v běžných scénářích vyvolat výjimky, aby nedocházelo k problémům s výkonem souvisejícím s výjimkami.

✔️ Používejte předponu "Try" a logický typ návratové hodnoty pro metody implementující tento vzorec.

✔️ Zadejte člena, který vyvolá výjimku pro každého člena pomocí vzoru Try-Parse.

Části z © 2005, 2009 Microsoft Corporation. Všechna práva vyhrazena.

Přetištěno se svolením Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition od Krzysztofa Cwaliny a Brada Abramse, vydáno 22. října 2008 nakladatelstvím Addison-Wesley Professional jako součást série Microsoft Windows Development.

Viz také

  • Last updated on