Niektóre wyjątki jakie mogą pojawić się w C#

Exception Na początku tworzenia wpisu miałem duży zapał ,ale gdy doszedłem do litery ”R” w wyjątkach z przestrzeni nazw System.SystemException to stwierdziłem , że zrobienie tej listy na pewno zajmie mi więcej niż jeden dzień.

Dla usprawnienia pracy podzieliłem wpis na części, ponieważ nie byłem w stanie  zbadać nawet tych wyjątków do litery R.

Mimo to myślę ,że będziesz zadowolony z mojej pracy. Na początku chciałem zrobić jedną wielką tabelkę ,ale byłaby ona nieczytelna i trudno by  było na niej zaznaczyć dziedziczenie, więc pomysł ten porzuciłem.

Celem tego wpisu nie jest nauczenie się wszystkich wyjątków na pamięć ,ale po prostu uświadomienie sobie ,że one istnieją.

Chociaż warto zapamiętać parę z nich.

Lista Wyjątków ArgumentException

Jednym z najczęściej spotykanych wyjątków jest ArgumentException. Tyle razy podawałem  niewłaściwy argument do danej  metody ,że go zapamiętałem.

Rodzina wyjątków ArgumentException  zawiera w sobie też inne przypadki niż błędny argument do metody X.

Przeglądając tę rodzinę zaciekawił mnie wyjątek InvalidEnumArgumentException. Szczerze mówiąc nawet nie wiedziałem ,że da się umieścić błędną wartość do typu wyliczeniowego. Przykład z MSDN jednak wykazał coś innego. Można umieścić błędną wartość poprzez błędne rzutowanie tylko po co to robić.
.

Oto wyjątki pochodzące z Argument Exception i jego synowie.

Lista Wyjątków ArithmeticException

Wyjątki, tym razem arytmetyczne związane są z klasą ArithmeticException i jego pochodnymi klasami.
Ogólnie trochę zdziwił mnie wyjątek NotFiniteNumberExceptionprzecież liczby double obsługują nieskończoność więc o co kaman ,czyżby wyjątek odnosił się do platformy.NET ,ale do innego języka niż C#. Zrobiłem małe badania w tej sprawie.

NotFiniteNumberException is available for programming languages that do not support the concepts of infinity and Not-a-Number in floating-point operations.

W dokumentacji można przeczytać następujące zdanie, które potwierdziło moją tezę.

ADO.NET

W System.Exception oczywiście nie zabrakło wyjątków z ADO.NET. Zaznaczyłem na żółto wyjątki, z którymi spotkałem się używając klas DataSet.

Wyjątek	Opis
DataException	Wyjątek pojawiający się przy niewłaściwej operacji baz danych przy użyciu komponentów z ADO.NET. Kolejny wyjątek, który ma naprawdę dużą rodzinę
DeletedRowInaccessibleException	Próba wykonania akcji na DataRow, który został już skasowany.
TypedDataSetGeneratorException	Występuje konflikt nazw przy generowaniu DataSet
DuplicateNameException	Próba dodania nowej bazy,tabeli,kolumny,relacji pod nazwą, która już istnieje.
InRowChangingEventException	Próba wywołania metody EndEdit wewnątrz wydarzenia RowChanging.
InvalidConstraintException	Niewłaściwa próba utworzenia bądź uzyskania dostępu do relacji.
InvalidExpressionException	Próba dodania kolumny poprzez błędne wyrażenie w kolekcji kolumn.
MissingPrimaryKeyException	Próba dostępu do wierszy w tabeli w pewien określony sposób (DataRowCollection.Contains,DataRowCollection.Find), która nie ma klucza indeksującego .
NoNullAllowedException	Próba dodania pustego rekordu do kolumny gdzie pole nie może być puste.
ObjectNotFoundException	Obiekt nie ma reprezentacji w bazie.
ReadOnlyException	Próba zmiany pola, w którym kolumna jest tylko do odczytu.
RowNotInTableException	Próba dokonania operacji na DataRow, którego nie ma w tabeli (DataTable). Tak pamiętam ten wyjątek.
StrongTypingException	Gdy użytkownik ma dostęp do wartości DBNull w silny typowany DataSet
TypedDataSetGeneratorException	Przy tworzeniu silnego typowanego DataSet wystąpił konflikt nazw.
UpdateException	Wyjątek zostanie rzucony przy próbie modyfikacji obiektu, który nie może być rzutowany na źródło danych.
VersionNotFoundException	Próba zwrócenia innej wersji DataRow do bazy, jednak on już został skasowany.

W wyjątku DataException naturalnie zawiera się też wyjątek EnityException ,a w nim wyjątki obsługujące ADO.NET Entity Framework.

Format Exception

FormatException to kolejny często spotykany wyjątek wynikający choćby z konwersji napisów liczbowych na typy liczbowe.

W czasie czytania dokumentacji MSDN coś przyszło mi do głowy, czy przypadkiem FormatException i ArgumentException nie robią tego samego ,a jeśli tak to dlaczego nie dziedziczą po sobie.

FormatException is thrown when the format of an argument in a method invocation does not match the format of the corresponding formal parameter type. For example, if a method specifies a String parameter consisting of two digits with an embedded period, passing a corresponding string argument containing only two digits to that method would cause FormatException to be thrown.

Akurat artykuł na MSDN na temat FormatExceptionmoże sprawiać takie wrażenie ,ale te dwa wyjątki się różnią jak dzień i noc.

FormatException zaznacza ,że problem nie wystąpił z powodu niezgodności typu, bo w końcu dla metody int.Parse() podajemy string więc problem z tym napisem tkwi w jego formacie, który nie jest liczbowym.

Dla lepszego przykładu mogę podać strumień dla metody , BinaryReader.Read7BitEncodedIn .Jeśli strumień nie jest  kodowany w 7 bitowym stylu wyrzuci mi wyjątek FormatException.

Przy okazji ten wyjątek też mógłby być obsłużony przez jego pochodnego kolegę FileFormatException ,ale nie jestem tego pewien ,ale istniałby sens dziedziczenia wyjątków.

To co mam na myśli to, to ,że klasy pochodne od danego wyjątku są bardziej dostosowane do konkretnych sytuacji (przykład: WyjątekZłyFormatPliku) ,ale wciąż wynikają one z klasy bazowej (“WyjątekZłyFormat”) .

FormatException i jego klasy pochodne.

IO Exception

IOException , który zaznacza błędne operacje IO i jego klasy pochodne, które  dostosowane są do konkretnych sytuacji. Myślę , że  opis ich w tabelce jest wystarczający.