Zgłaszanie wyjątku
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.
Wytyczne dotyczące zgłaszania wyjątków opisane w tej sekcji wymagają dobrej definicji znaczenia niepowodzenia wykonywania. Niepowodzenie wykonywania występuje zawsze, gdy członek nie może zrobić tego, co został zaprojektowany do wykonania (co oznacza nazwa elementu członkowskiego). Jeśli na przykład OpenFile metoda nie może zwrócić otwartego dojścia pliku do elementu wywołującego, zostanie uznana za niepowodzenie wykonywania.
Większość deweloperów przyzwyczaiła się do używania wyjątków dla błędów użycia, takich jak dzielenie przez odwołania zerowe lub zerowe. W strukturze wyjątki są używane dla wszystkich warunków błędów, w tym błędów wykonywania.
❌ NIE zwracaj kodów błędów.
Wyjątki są podstawowymi metodami raportowania błędów w strukturach.
✔️ Nie można zgłaszać błędów wykonywania raportów przez zgłaszanie wyjątków.
✔️ Rozważ zakończenie procesu przez wywołanie System.Environment.FailFast funkcji (funkcja .NET Framework 2.0) zamiast zgłaszania wyjątku, jeśli kod napotka sytuację, w której jest niebezpieczna do dalszego wykonywania.
❌ NIE należy używać wyjątków dla normalnego przepływu sterowania, jeśli to możliwe.
Z wyjątkiem awarii systemu i operacji z potencjalnymi warunkami wyścigu projektanci struktury powinni projektować interfejsy API, aby użytkownicy mogli pisać kod, który nie zgłasza wyjątków. Na przykład można zapewnić sposób sprawdzania warunków wstępnych przed wywołaniem elementu członkowskiego, aby użytkownicy mogli pisać kod, który nie zgłasza wyjątków.
Element członkowski używany do sprawdzania warunków wstępnych innego elementu członkowskiego jest często określany jako tester, a element członkowski, który faktycznie wykonuje pracę, jest nazywany wykonawcą.
Istnieją przypadki, gdy wzorzec testera-doera może mieć niedopuszczalne obciążenie związane z wydajnością. W takich przypadkach należy wziąć pod uwagę tzw Wzorzec try-parse (zobacz Wyjątki i wydajność , aby uzyskać więcej informacji).
✔️ ROZWAŻ implikacje dotyczące wydajności zgłaszania wyjątków. Współczynniki rzutu powyżej 100 na sekundę mogą znacząco wpłynąć na wydajność większości aplikacji.
✔️ DOKUMENTUj wszystkie wyjątki zgłaszane przez publicznie wywoływanych członków z powodu naruszenia umowy członka (a nie awarii systemu) i traktuj je w ramach umowy.
Wyjątki będące częścią kontraktu nie powinny zmieniać się z jednej wersji na następną (tj. nie należy zmieniać typu wyjątku, a nie należy dodawać nowych wyjątków).
❌ NIE MAJĄ publicznych członków, którzy mogą zgłaszać lub nie opierać się na niektórych opcjach.
❌ NIE MAJĄ publicznych elementów członkowskich, które zwracają wyjątki jako wartość zwracaną out lub parametr.
Zwracanie wyjątków z publicznych interfejsów API zamiast zgłaszania ich pokonuje wiele korzyści z raportowania błędów opartych na wyjątkach.
✔️ ROZWAŻ użycie metod konstruktora wyjątków.
Często zgłaszany jest ten sam wyjątek z różnych miejsc. Aby uniknąć wzdęć kodu, użyj metod pomocnika, które tworzą wyjątki i inicjują ich właściwości.
Ponadto członkowie, którzy zgłaszają wyjątki, nie są wciśnięci. Przeniesienie instrukcji throw wewnątrz konstruktora może umożliwić podkreślenie elementu członkowskiego.
❌ NIE zgłaszaj wyjątków z bloków filtru wyjątków.
Gdy filtr wyjątku zgłosi wyjątek, wyjątek zostanie przechwycony przez CLR, a filtr zwraca wartość false. To zachowanie jest nie do odróżnienia od filtru wykonującego i zwracającego wartość false jawnie i dlatego jest bardzo trudne do debugowania.
❌ UNIKAJ jawnego zgłaszania wyjątków z bloków końcu. Niejawnie zgłaszane wyjątki wynikające z wywoływania metod, które zgłaszają, są dopuszczalne.
© 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.