Uwaga
Dostęp do tej strony wymaga autoryzacji. Może 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.
W tej sekcji opisano standardowe wyjątki udostępniane przez platformę i szczegóły ich użycia. Lista nie jest w żaden sposób wyczerpująca. Zapoznaj się z dokumentacją referencyjną programu .NET Framework, aby zapoznać się z użyciem innych typów wyjątków platformy Framework.
Wyjątek i SystemException
❌ NIE rzucaj System.Exception ani System.SystemException.
❌ NIE przechwytuj System.Exception ani System.SystemException w kodzie struktury, chyba że zamierzasz ponownie wywrócić.
❌ UNIKAJ przechwytywania System.Exception lub System.SystemException, z wyjątkiem procedur obsługi wyjątków najwyższego poziomu.
ApplicationException
❌ NIE rzucaj lub dziedzicz z ApplicationException.
WyjątekNiepoprawnejOperacji
✔️ Rzucaj błąd InvalidOperationException, jeśli obiekt jest w niewłaściwym stanie.
ArgumentException, ArgumentNullException i ArgumentOutOfRangeException
✔️ Wyrzuć ArgumentException lub jeden z jego podtypów, jeśli złe argumenty zostały przekazane do członu. Preferuj najbardziej pochodny typ wyjątku, jeśli ma to zastosowanie.
✔️ Ustaw właściwość ParamName podczas rzucania jednej z podklas klasy ArgumentException.
Ta właściwość reprezentuje nazwę parametru, który spowodował zgłoszenie wyjątku. Należy pamiętać, że właściwość można ustawić poprzez użycie jednego z przeciążeń konstruktora.
✔️ KONIECZNIE użyj value dla nazwy niejawnego parametru wartości ustawników właściwości.
NullReferenceException, IndexOutOfRangeException i AccessViolationException
❌ Nie zezwalaj publicznie wywoływanym interfejsom API jawnie lub niejawnie zgłaszać NullReferenceException, AccessViolationExceptionlub IndexOutOfRangeException. Te wyjątki są zarezerwowane i zgłaszane przez silnik wykonawczy, a w większości przypadków wskazują na błąd w oprogramowaniu.
Wykonaj sprawdzanie argumentów, aby uniknąć zgłaszania tych wyjątków. Zgłaszanie tych wyjątków uwidacznia szczegóły implementacji metody, które mogą ulec zmianie w czasie.
StackOverflowException
❌ Nie zgłaszaj jawnie StackOverflowException. Wyjątek powinien być jawnie zgłaszany tylko przez CLR.
❌ NIE przechwytuj StackOverflowException.
Napisanie kodu zarządzanego, który pozostaje spójny w przypadku dowolnych przepełnień stosu, jest prawie niemożliwe. Niezarządzane części środowiska CLR pozostają spójne, używając sond do przenoszenia sytuacji przepełnienia stosu do jasno zdefiniowanych lokalizacji zamiast wycofywania się z nieokreślonych sytuacji przepełnienia stosu.
OutOfMemoryException
❌ Nie zgłaszaj jawnie OutOfMemoryException. Ten wyjątek ma być rzucany wyłącznie przez infrastrukturę CLR.
ComException, SEHException i ExecutionEngineException
❌ NIE zgłaszaj jawnie COMException, ExecutionEngineException ani SEHException. Te wyjątki mają być zgłaszane tylko przez infrastrukturę CLR.
© 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.