Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga / Notatka
Ta treść jest przedrukowana za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2. wydanie. 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 w wykonaniu. Błąd wykonania występuje, gdy członek nie może zrobić tego, do czego został zaprojektowany (co sugeruje nazwa członka). 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 zero lub odwołania null. W ramach oprogramowania wyjątki są używane dla wszystkich przypadków błędów, w tym błędów podczas wykonywania.
❌ NIE zwracaj kodów błędów.
Wyjątki są podstawowymi metodami raportowania błędów w strukturach.
✔️ Zgłaszaj błędy wykonania poprzez rzucanie 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 współbieżności, 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 członka, 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, w których wzorzec Tester-Doer 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 ich zgłaszania neguje wiele korzyści wynikających z raportowania błędów opartych na wyjątkach.
✔️ ROZWAŻ użycie metod konstruktora wyjątków.
Często rzuca się ten sam wyjątek w różnych miejscach. Aby uniknąć przerostu kodu, użyj metod pomocniczych, które tworzą wyjątki i inicjują ich właściwości.
Ponadto członkowie, którzy rzucają wyjątki, nie są inlinizowani. Przeniesienie instrukcji throw wewnątrz budowniczego może umożliwić inline'owanie członu.
❌ NIE zgłaszaj wyjątków z bloków filtrowania 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 działania filtru, który jawnie wykonuje się i zwraca wartość false, i dlatego jest bardzo trudne do debugowania.
❌ UNIKAJ jawnego zgłaszania wyjątków z bloków finally. Zgłaszanie wyjątków w sposób niejawny, wynikających z wywoływania metod, które je rzucają, jest dopuszczalne.
© Części 2005, 2009 Microsoft Corporation. Wszelkie prawa zastrzeżone.
Przedrukowane za zgodą Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition przez Krzysztofa Cwalinę i Brada Abramsa, opublikowane 22 października 2008 przez Addison-Wesley Professional w ramach serii Microsoft Windows Development.