Używanie standardowych typów wyjątków
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.
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 wyjątek SystemException
❌ NIE zgłaszaj 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 należy zgłaszać ani pochodzić z elementu ApplicationException.
InvalidOperationException
✔️ Wyrzuć obiekt 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 są przekazywane do elementu członkowskiego. Preferuj najbardziej pochodny typ wyjątku, jeśli ma to zastosowanie.
✔️ Ustaw właściwość podczas ParamName zgłaszania 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ć przy użyciu jednego z przeciążeń konstruktora.
✔️ Użyj funkcji value DO dla nazwy niejawnego parametru wartości zestawó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 aparat wykonywania, a w większości przypadków wskazują usterkę.
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 StackOverflowExceptionjawnie . Wyjątek powinien być jawnie zgłaszany tylko przez CLR.
❌ NIE przechwytuj StackOverflowException.
Prawie niemożliwe jest napisanie kodu zarządzanego, który pozostaje spójny w obecności dowolnych przepełnienia stosu. Niezarządzane części środowiska CLR pozostają spójne przy użyciu sond do przenoszenia przepełnienia stosu do dobrze zdefiniowanych miejsc, a nie przez wycofywanie z dowolnych przepełnienia stosu.
Outofmemoryexception
❌ NIE ZGŁASZAJ OutOfMemoryExceptionjawnie . Ten wyjątek należy zgłosić tylko przez infrastrukturę CLR.
ComException, SEHException i ExecutionEngineException
❌ NIE zgłaszaj COMExceptionjawnie , ExecutionEngineExceptioni SEHException. Te wyjątki mają być zgłaszane tylko przez infrastrukturę CLR.
© 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.