Блок finally

Блок finally содержит код, исполнение которого гарантируется. Обычно этот код выполняет операции очистки, необходимые в результате выполненных в блоке try действий. Так, если в блоке try был открыт файл, то в блоке, finally должен быть код, закрывающий этот файл.

Если код из блока try не вызовет исключение, то файл гарантированно будет закрыт; и, даже если возникнет исключение, код из блока finally будет выполнен, а файл — закрыт независимо от того, перехвачено ли исключение. Не следует помещать оператор, закрывающий файл, после блока finally — он не будет исполнен, если сгенерированное исключение не будет перехвачено, и в итоге файл останется открытым.

Вовсе не обязательно, чтобы с блоком try был связан блок finally. Иногда код в блоке try просто не требует никакого кода для очистки. Но если блок finally все же имеется, он должен размещаться после всех блоков catch, причем блоку try может соответствовать не более одного блока finally.

Дойдя до конца кода в блоке finally, поток просто начинает исполнять операторы, расположенные за блоком finally. Код в блоке finally предназначен для очистки и должен делать только то, что необходимо для отмены операций, начатых в блоке try. Избегайте в блоке finally кода, способного сгенерировать исключение. Но даже если возникло исключение в блоке finally, это еще не конец света — механизм обработки исключений среды CLR продолжит исполнение, как будто бы исключение было сгенерировано после блока finally. Но при этом CLR напрочь «забудет» об исходном исключении, возникшем в блоке try (если таковое было), и вся информация (в частности, трассировочный след в стеке вплоть до исключения) о таком исключении будет потеряна.

Генерация исключений

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

■ Какой производный от Exception тип исключения будет генерироваться? Настоятельно рекомендуется выбирать содержательный тип. Представьте себе код, расположенный выше в стеке вызовов, и как тот код должен узнать, что метод потерпел неудачу, чтобы выполнить корректное восстановление после сбоя. Можно задействовать тип, уже определенный в FCL, но может быть, что в FCL нет типа, полностью соответствующего нужной семантике. Поэтому придется определять собственный тип, непосредственно наследующий SystemException. Если нужно определить иерархию типов исключений, настоятельно рекомендуется создавать максимально плоскую и широкую иерархию, чтобы свести до минимума число базовых классов. Причина в том, что базовые классы действуют так, чтобы обеспечить обработку многих ошибок как одной ошибки, и это обычно опасно. Таким образом, никогда не следует генерировать тип SystemException и надо соблюдать максимальную осторожность при генерации любого другого типа исключений, являющегося базовым классом.

■ Какое строковое сообщение передавать в конструктор типа исключения? При генерации исключения нужно предоставлять строковое сообщение с детальной информацией о том, почему метод не смог выполнить свою задачу. Если исключение перехватывается и обрабатывается, это строковое сообщение не видно. А вот сообщения необработанных исключений обычно регистрируются в журнале. Необработанное исключение информирует о настоящем дефекте приложения, и разработчик программы должен позаботиться об искоренении дефекта. У конечного пользователя нет исходного текста и возможности исправить недостаток кода и перекомпоновать программу. Вообще говоря, это строковое сообщение конечный пользователь видеть не должен, поэтому оно может содержать массу технических деталей и предоставлять всю необходимую разработчикам информацию для устранения дефекта в коде. Кроме того, так как все разработчики должны понимать английский (ведь языки программирования и FCL-классы и методы содержат много английских слов), обычно нет нужды локализовывать строковые сообщения исключений. Впрочем, вы вправе локализовать строки, если создаете библиотеку классов для разработчиков, говорящих на других языках. В Microsoft локализуют сообщения исключений, генерируемых FCL, так как эту библиотеку классов используют разработчики, разговаривающие на самых разных языках.