Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

// Этот программный код не компилируется!

static void Main(string[] args) {

…

try {

for (int i = 0; i ‹ 10; i++) myCar.Accelerate(10);

} catch(Exception e) {

// Обработка всех остальных исключений?

} catch(CarIsDeadException e) {

// Обработка CarIsDeadException.

} catch(ArgumentOutOfRangeException e) {

// Обработка ArgumentOutOfRangeException.

}

…

}

Такая логика обработки исключений порождает ошибки компиляции. Проблема в том, что первый блок catch может обработать все , что оказывается производным от System.Exception, включая типы CarIsDeadException и ArgumentOutOfRangeException. Таким образом, оставшиеся два блока catch оказываются просто недостижимыми!

Правило, которое следует использовать на практике, заключается в необходимости размещать блоки catch так, чтобы первый блок соответствовал самому "частному" исключению (т.е. самому младшему производному типу в цепочке наследования), а последний блок – самому "общему" (т.е. базовому классу данной цепочки, в данном случае это System.Exception).

Поэтому если вы хотите определить оператор catch, который обработает все ошибки после CarIsDeadException и ArgumentOutOfRangeException, вы должны записать следующее.

// Этот программный код будет скомпилирован.

static void Main(string[] args) {

…

try {

for (int i = 0; i ‹ 10; i++) myCar.Accelerate(10);

} catch(CarIsDeadException e) {

// Обработка CarIsDeadException.

} catch(ArgumentOutOfRangeException) {

// Обработка ArgumentOutOfRangeException.

} catch (Exception e) {

// Здесь будут обработаны все остальные возможные исключения,

// генерируемые операторами в рамках try.

}

…

}

В C# также поддерживается "общий" блок catch, который не получает явно объект исключения, генерируемый данным членом.

// Блок catch общего вида.

static void Main(string[] args) {

…

try {

for (int i = 0; i ‹ 10; i++) myCar.Accelerate(10);

} catch {

Console.WriteLine("Случилось что-то ужасное…");

}

…

}

Очевидно, что это не самый информативный способ обработки исключения, поскольку здесь вы не имеете возможности получить содержательную информацию о произошедшей ошибке (например, имя метода, содержимое стека вызовов или пользовательское сообщение). Тем не менее, в C# такая конструкция возможна.

Вы должны знать, что в рамках логики try имеется возможность генерировать исключение для вызывающей стороны, находящейся выше по цепочке вызовов в стеке вызовов. Для этого просто используйте ключевое слово throw в рамках блока сatch. Тем самым исключение будет направлено выше по цепочке логики вызовов, что может быть полезно тогда, когда данный блок catch не имеет возможности полностью обработать возникшую ошибку.

// Перекладывание ответственности.

static void Main (string[] args) {

…

try {

// Логика ускорения автомобиля…}

catch(CarIsDeadException e) {

// Частичная обработка ошибки и перенаправление.

// Здесь перенаправляется входной объект CarIsDeadException.

// Но можно генерировать и другое исключение.

throw e;

}

…

}

Вы должны понимать, что в данном примере программного кода конечным получателем CarIsDeadException является среда CLR, поскольку здесь вторичное исключение генерируется методом Main(). Поэтому вашему конечному пользователю будет представлено системное диалоговое окно с информацией об ошибке. Как правило, вторично сгенерированное и частично обработанное исключение предъявляется вызывающей стороне, которая имеет возможность обработать его более "грациозно".

Вы можете догадываться, что вполне возможно генерировать исключения и во время обработки другого исключения. Например, предположим, что вы обрабатываете CarIsDeadException в рамках конкретного блока catch и в процессе обработки пытаетесь записать след стека в файл carErrors.txt на вашем диске C.

catch(CarlsDeadException e) {

// Попытка открыть файл carErrors.txt на диске C.

FileStream fs = File.Open(@"C:\carErrors.txt", FileMode.Open);

…

}

Если указанный файл на диске C не найден, попытка вызова File.Open() даст в результате FileNotFoundException. Позже мы рассмотрим пространство имен System.IO и выясним, как перед открытием файла можно программными средствами проверить наличие файла на жестком диске (и предотвратить возможность возникновения исключения). Однако здесь, чтобы сосредоточиться на теме исключений, мы предполагаем, что исключение возникло.

Когда во время обработки одного исключения обнаруживается другое исключение, лучше всего записать новый объект исключения, как "внутреннее исключение" в рамках нового объекта того же типа, что и исходное исключение (язык сломаешь!). Причина, по которой мы должны создавать новый объект исключения, заключается в том, что единственным способом документирования внутреннего исключения оказывается использование параметров конструктора. Рассмотрите следующий фрагмент программного кода.

catch (CarIsDeadException e) {

try {

FileStream fs = File.Open(@"C:\carErrors.txt", FileMode.Open);

…

} catch(Exception e2 ) {

// Генерирование исключения, записывающего новое исключение

// и сообщение первого исключения.

throw new CarIsDeadException(e.Message, e2);

}

}

Заметьте, что в данном случав мы передали объект FileNotFoundException конструктору CarIsDeadException в виде второго параметра. Сконфигурировав этот новый объект, мы направляем его по стеку вызовов следующему вызывающему объекту, в данном случае по отношению к методу Main().

С учетом того, что после Main() "следующих вызывающих объектов" для обработки исключений нет , мы снова должны увидеть диалоговое окно с сообщением об ошибке. Во многом подобно генерированию вторичных исключений, запись внутренних исключений обычно оказывается полезной только тогда, когда вызывающий объект имеет возможность красиво обработать такое исключение. В этом случае логика catch вызывающей стороны может использовать свойство InnerException для получения подробной информации об объекте внутреннего исключения.

В рамках try/catch можно также определить необязательный блок finally. Задача блока finally – обеспечить безусловное выполнение некоторого набора операторов программного кода, независимо от наличия или отсутствия исключения (любого типа). Для примера предположим, что вы хотите всегда выключать радио автомобиля перед выходом из Main(), независимо от исключений.