Язык программирования C#9 и платформа .NET5

С учетом приведенных определений должно быть понятно, что структурированная обработка исключений в .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

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

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

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

• блок кода на вызывающей стороне, который обращается к члену, предрасположенному к возникновению исключения;

• блок кода на вызывающей стороне, который будет обрабатывать (или перехватывать) исключение, если оно возникнет.

Язык программирования C# предлагает пять ключевых слов (try, catch, throw, finally и when), которые позволяют генерировать и обрабатывать исключения. Объект, представляющий текущую проблему, относится к классу, который расширяет класс System.Exception (или производный от него класс). С учетом сказанного давайте исследуем роль данного базового класса, касающегося исключений.

Базовый класс System.Exception

Все исключения в конечном итоге происходят от базового класса System.Exception, который в свою очередь является производным от System.Object. Ниже показана основная часть этого класса (обратите внимание, что некоторые его члены являются виртуальными и, следовательно, могут быть переопределены в производных классах):

 public class Exception : ISerializable
 {
  // Открытые конструкторы
  public Exception(string message, Exception innerException);
  public Exception(string message);
  public Exception;
  ...

  // Методы
  public virtual Exception GetBaseException;
  public virtual void GetObjectData(SerializationInfo info,
  StreamingContext context);