Язык программирования C#9 и платформа .NET5 - Эндрю Троелсен

Глава 7

Структурированная обработка исключений

В настоящей главе вы узнаете о том, как иметь дело с аномалиями, возникающими во время выполнения кода С#, с использованием структурированной обработки исключений. Будут описаны не только ключевые слова С#, предназначенные для этих целей (try, catch, throw, finally, when), но и разница между исключениями уровня приложения и уровня системы, а также роль базового класса System.Exception. Кроме того, будет показано, как создавать специальные исключения, и рассмотрены некоторые инструменты отладки в Visual Studio, связанные с исключениями.

Ода ошибкам, дефектам и исключениям

Что бы ни нашептывало наше (порой завышенное) самомнение, идеальных программистов не существует. Разработка программного обеспечения является сложным делом, и из-за такой сложности довольно часто даже самые лучшие программы поставляются с разнообразными проблемами. В одних случаях проблема возникает из-за "плохо написанного" кода (например, по причине выхода за границы массива), а в других — из-за ввода пользователем некорректных данных, которые не были учтены в кодовой базе приложения (скажем, когда в поле для телефонного номера вводится значение вроде Chucky). Вне зависимости от причин проблемы в конечном итоге приложение не работает ожидаемым образом. Чтобы подготовить почву для предстоящего обсуждения структурированной обработки исключений, рассмотрим три распространенных термина, которые применяются для описания аномалий.

• Дефекты. Выражаясь просто, это ошибки, которые допустил программист. В качестве примера предположим, что вы программируете на неуправляемом C++. Если вы забудете освободить динамически выделенную память, что приводит к утечке памяти, тогда получите дефект.

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

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

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

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

На заметку! Чтобы сделать примеры кода максимально ясными, мы не будем перехватывать абсолютно все исключения, которые может выдавать заданный метод из библиотеки базовых классов. Разумеется, в своих проектах производственного уровня вы должны широко использовать приемы, описанные в главе.

Роль обработки исключений .NET

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

/* Типичный механизм перехвата ошибок в стиле С. */

#define E_FILENOTFOUND 1000

int UseFileSystem()

{

  // Предполагается, что в этой функции происходит нечто

  // такое, что приводит к возврату следующего значения.

  return E_FILENOTFOUND;

}

void main()

{

  int retVal = UseFileSystem();

  if(retVal == E_FILENOTFOUND)

    printf("Cannot find file...");  // H e удалось найти файл

}

Такой подход далек от идеала, учитывая тот факт, что константа E_FILENOTFOUND — всего лишь числовое значение, которое немногое говорит о том, каким образом решить возникшую проблему. В идеале желательно, чтобы название ошибки, описательное сообщение и другая полезная информация об условиях возникновения ошибки были помещены в единственный четко определенный пакет (что как раз и происходит при структурированной обработке исключений). В дополнение к специальным приемам, к которым прибегают разработчики, внутри API-интерфейса Windows определены сотни кодов ошибок, которые поступают в виде определений #define и HRESULT, а также очень многих вариаций простых булевских значений (bool, BOOL, VARIANT_BOOL и т.д.).

Очевидной проблемой, присущей таким старым приемам, является полное отсутствие симметрии. Каждый подход более или менее подгоняется под заданную технологию, заданный язык и возможно даже заданный проект. Чтобы положить конец такому безумству, платформа .NET предложила стандартную методику для генерации и перехвата ошибок времени выполнения — структурированную обработку исключений. Достоинство этой методики в том, что разработчики теперь имеют унифицированный подход к обработке ошибок, который является общим для всех языков, ориентированных на .NET. Следовательно, способ обработки ошибок, используемый программистом на С#, синтаксически подобен способу, который применяет программист на VB или программист на C++, имеющий дело с C++/CLI.

Дополнительное преимущество связано с тем, что синтаксис, используемый для генерации и отлавливания исключений за пределами границ сборок и машины, идентичен. Скажем, если вы применяете язык C# при построении REST-службы ASP.NET Core, то можете сгенерировать исключение JSON для удаленного вызывающего кода, используя те же самые ключевые слова, которые позволяют генерировать исключения внутри методов одного приложения.

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

Строительные блоки обработки исключений в .NET

Программирование со структурированной обработкой исключений предусматривает применение четырех взаимосвязанных сущностей:

• тип класса, который представляет детали исключения;

• член, способный генерировать