Обработка и создание исключений в .NET

Необходимо реализовать возможность единообразной обработки приложениями ошибок, происходящих во время выполнения. Среда .NET предоставляет модель для единообразного уведомления приложений об ошибках: операции .NET информируют о сбое посредством выдачи исключений.

Исключения

Исключение — это любое состояние ошибки или непредвиденное поведение, возникающее при выполнении программы. Исключения могут возникать из-за сбоя в вашем или вызываемом коде (например, в общей библиотеке), недоступности ресурсов ОС, неожиданных состояний, возникающих в среде выполнения (например, код, который невозможно проверить) и по другим причинам. После некоторых из этих состояний приложение может восстановиться, после других — нет. В большинстве случаев вы можете выполнить восстановление после большинства исключений в приложении, но не после исключений среды выполнения.

В .NET исключение — это объект, наследуемый от класса System.Exception. Исключение создается из области кода, где произошла проблема. Исключение передается вверх по стеку до тех пор, пока его не обработает приложение либо программа не завершится.

Исключения и традиционные методы обработки ошибок

Традиционно модели обработки ошибок разных языков программирования основываются либо на уникальном для языка способе обнаружения ошибок и отыскании для них обработчиков, либо на механизме обработки ошибок, предоставляемом операционной системой. Способ обработки исключений, реализуемый в .NET, обладает следующими преимуществами:

• Создание и обработка исключений работают одинаково для языков программирования .NET.
• Не требует определенного синтаксиса языка для обработки исключений, а позволяет каждому языку определить собственный синтаксис.
• Исключения можно создавать между разными процессами и даже компьютерами.
• В приложение можно добавить код обработки исключений для повышения надежности программы.

Исключения обеспечивают ряд преимуществ по сравнению с другими методами уведомления об ошибках, например кодами возврата. Сбои не остаются незамеченными, так как среда выполнения завершает работу приложения при наличии необработанного исключения. Недопустимые значения не распространяются по системе из-за того, что код не способен выполнить проверку кода возврата ошибки.

Часто встречающиеся исключения

В следующей таблице перечислены некоторые общие исключения с примерами возможных причин.

Тип исключения	Описание	Пример
Exception	Базовый класс для всех исключений.	Отсутствует (используйте производный класс этого исключения).
IndexOutOfRangeException	Вызывается средой выполнения только при неправильной индексации массива.	Индексирование массива вне допустимого диапазона: arr[arr.Length+1]
NullReferenceException	Вызывается средой выполнения только в том случае, если имеется ссылка на пустой объект.	object o = null; o.ToString();
InvalidOperationException	Вызывается методами в недопустимом состоянии.	Вызов Enumerator.MoveNext() после удаления элемента из базовой коллекции.
ArgumentException	Базовый класс для всех исключений аргументов.	Отсутствует (используйте производный класс этого исключения).
ArgumentNullException	Вызывается методами, которые не допускают пустой аргумент.	String s = null; “Calculate”.IndexOf(s);
ArgumentOutOfRangeException	Вызывается методами, проверяющими попадание аргументов в заданный диапазон.	String s = “string”; s.Substring(s.Length+1);

См. также

• Класс Exception и его свойства
• Практическое руководство. Использование блока try/catch для перехвата исключений
• Практическое руководство. Использование определенных исключений в блоке catch
• Практическое руководство. Явное создание исключений
• Практическое руководство. Создание пользовательских исключений
• Использование обработчиков исключений с пользовательской фильтрацией
• Практическое руководство. Использование блоков Finally
• Обработка исключений COM-взаимодействия
• Рекомендации по обработке исключений
• What Every Dev needs to Know About Exceptions in the Runtime (Что нужно знать всем разработчикам об исключениях в среде выполнения).

Когда нужны исключения

Тема Исключений (за и против) не нова, и уже не раз обсуждалась. Но всё же, я надеюсь, что каждый из прочитавших данную статью почерпнёт что-то новое и полезное для себя.

Причиной появления этой публикации стало нежелание больше молчать и просто смотреть, как интернет заполняют «всезнающие» программисты, которые учат новичков в нашей сфере забивать гвозди микроскопом, находя десятки аргументов в защиту своих методов! Потому, эта публикация направлена, скорее, на новичка постигающего программирование и задающего вопросы. Она является моим «правильным ответом»

Итак, что же такое Исключение (Exception)?

Исключение — это то, вероятность (возможность) чего исключается системой… это то что в условиях программы произойти не может.

Посмотрите в свой код. Можете ли вы к каждому исключению дописать «но ведь это невозможно» или «но это же исключено»? Думаю, мало кто сможет честно ответить «да». Если ваш ответ «нет» — значит часть исключений на самом деле не являются таковыми, просто вы использовали этот механизм, потому как вам показалось это более удобным. То самое «удобство» такого подхода будет рассмотрено далее.

Кто же должен определять, какие ситуации программа исключает, а какие нет?

Все исключения могут быть продиктованы только заданием или здравым смыслом, и ничем или никем иным. Исключение не определяется ни типом данных, ни их источником, хотя нередко можно услышать или прочитать в «умных» статьях: «Неправильный клиентский ввод не может быть исключением»… не верьте! Вот, просто, не надо в такое верить.

Вы можете в задании получить вполне разумное исключение неверного клиентского ввода: «С системой будут работать специально обученные менеджеры нашей компании, потому ввод неправильных данных исключён» или «Менеджер будет загружать в систему письма, которые уже прошли проверку правильности формата, поэтому формат всегда будет именно такой». Вот теперь заказчик сам вам сказал, где следует породить исключение в написанной для него программе (и ничего страшного, что это клиентский ввод). Разумеется, если речь всё же идёт о неком продукте, а не библиотеке, программу не надо просто ронять. Пускай на верхнем уровне висит обработчик исключений и превращает все необработанные исключения в ошибки, сохраняет данные и деликатно завершает выполнение (или передаёт управление основному модулю, если ошибка не в нём).

Но, как и обычно, не забываем читать между строк и уточнять задание. Если вас просят сохранить файл, уточните, возможна ли ситуация, что файл не сохранится. А если решили не уточнять, тогда не исключайте такую вероятность, а реализуйте реакцию на это событие. Ваш код не должен ни о чём умалчивать.

Или предусмотрите, или исключите.

Почему любое лишнее Исключение является вредным для кода?

Не раз сталкивался с ситуацией, когда отрицательный результат выполнения функции возвращали в виде исключения, хотя такой результат был предусмотрен самой задачей. На этот счёт слышал разные пояснения:

• Не передавать же по всей цепочке вызовов флаг завершения
• Мне надо передать данные, собранные до получения отрицательного ответа
• Функция может вернуть отрицательный результат по трём причинам. Так проще передать эту причину
• множество других доводов.

Почему же так не надо делать? Да потому, что:

• Вы не сможете смело использовать уже написанные методы в других местах, ведь они могут порождать неожиданные исключения;

  Заключение

  Старался не вдаваться лишние подробности и в каждое предложение вкладывать максимум смысла. Надеюсь у меня это получилось, и читая эти строки, вы думаете: «пять минут, а столько нового!» Ну что же, надеюсь это так.

  Напоследок хотелось бы сказать, что не следует изворачиваться под давлением факторов, сроков и «так же проще», и писать неправильный код, зато быстро.

  Совершенство и отказоустойчивость нашего кода и определяет наш профессионализм.

  • совершенный код
  • исключения

  При подготовке материала использовались источники:
  https://learn.microsoft.com/ru-ru/dotnet/standard/exceptions/
  https://habr.com/ru/articles/311214/