Wyjątki i wydajność
Uwaga
Ta zawartość jest drukowana przez uprawnienie Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Wydanie to zostało opublikowane w 2008 roku, a książka została w pełni zmieniona w trzecim wydaniu. Niektóre informacje na tej stronie mogą być nieaktualne.
Jednym z typowych problemów związanych z wyjątkami jest to, że jeśli wyjątki są używane dla kodu, który rutynowo kończy się niepowodzeniem, wydajność implementacji będzie niedopuszczalna. Jest to istotny problem. Gdy członek zgłasza wyjątek, jego wydajność może być rzędu wielkości wolniej. Jednak można osiągnąć dobrą wydajność, ściśle przestrzegając wytycznych dotyczących wyjątków, które nie zezwalają na używanie kodów błędów. Dwa wzorce opisane w tej sekcji sugerują sposoby, aby to zrobić.
❌ NIE używaj kodów błędów z powodu obaw, że wyjątki mogą negatywnie wpłynąć na wydajność.
Aby zwiększyć wydajność, można użyć wzorca Tester-Doer lub Try-Parse Pattern, opisanego w dwóch następnych sekcjach.
Wzorzec testera-doera
Czasami wydajność elementu członkowskiego zgłaszającego wyjątek może zostać ulepszona przez podzielenie elementu członkowskiego na dwa. Przyjrzyjmy Add się metodzie interfejsu ICollection<T> .
ICollection<int> numbers = ...
numbers.Add(1);
Metoda Add zgłasza, jeśli kolekcja jest tylko do odczytu. Może to być problem z wydajnością w scenariuszach, w których wywołanie metody często kończy się niepowodzeniem. Jednym ze sposobów rozwiązania problemu jest przetestowanie, czy kolekcja jest zapisywalna przed próbą dodania wartości.
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
Element członkowski używany do testowania warunku, który w naszym przykładzie jest właściwością IsReadOnly, jest określany jako tester. Element członkowski używany do wykonywania potencjalnie zgłaszającej operacji , Add metoda w naszym przykładzie jest określana jako osoba do wykonania.
✔️ ROZWAŻ wzorzec testera-doera dla członków, który może zgłaszać wyjątki w typowych scenariuszach, aby uniknąć problemów z wydajnością związanych z wyjątkami.
Wzorzec try-parse
W przypadku bardzo wrażliwych na wydajność interfejsów API należy użyć jeszcze szybszego wzorca niż wzorzec testera-doera opisany w poprzedniej sekcji. Wzorzec wywołuje dostosowanie nazwy elementu członkowskiego w celu utworzenia dobrze zdefiniowanego przypadku testowego jako części semantyki składowej. Na przykład definiuje metodęParse, DateTime która zgłasza wyjątek w przypadku niepowodzenia analizowania ciągu. Definiuje również odpowiednią TryParse metodę, która próbuje przeanalizować, ale zwraca wartość false, jeśli analizowanie nie powiedzie się i zwraca wynik pomyślnego analizowania przy użyciu parametru out .
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
W przypadku korzystania z tego wzorca ważne jest zdefiniowanie funkcji try w ścisłych kategoriach. Jeśli element członkowski zakończy się niepowodzeniem z jakiegokolwiek powodu innego niż dobrze zdefiniowana próba, członek musi nadal zgłaszać odpowiedni wyjątek.
✔️ ROZWAŻ wzorzec try-parse dla elementów członkowskich, które mogą zgłaszać wyjątki w typowych scenariuszach, aby uniknąć problemów z wydajnością związanych z wyjątkami.
✔️ Należy użyć prefiksu "Try" i typu zwracanego wartości logicznej dla metod implementowania tego wzorca.
✔️ Należy podać element członkowski zgłaszający wyjątek dla każdego elementu członkowskiego przy użyciu wzorca Try-Parse.
© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.
Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, published oct 22, 2008 by Addison-Wesley Professional w ramach Microsoft Windows Development Series.