// Генерируем пользовательское исключение CarIsDeadException.
public void Accelerate(int delta) {
...
CarIsDeadException ex = new CarIsDeadException(string.Format("{0} перегрелся!", petName));
ex.HelpLink = "http://www.CarsRUs.com";
ex.Data.Add("Дата и время", string.Format("Автомобиль сломался {0}", DateTime.Now));
ex.Data.Add("Причина", "У вас тяжелая нога.");
throw ex;
}
Чтобы выполнить явный захват поступившего исключения, блок catch следует изменить для захвата конкретного типа CarIsDeadException (однако, с учетом того, что System.CarIsDeadException является потомком System.Exception, можно также выполнить захват объекта System.Exception общего вида).
static void Main (string[] args) {
catch (CarIsDeadException e) {
// Обработка поступившего исключения.
}
}
Теперь, после рассмотрения основных этапов процесса создания пользовательских исключений, возникает вопрос: когда может потребоваться их создание? Как правило, пользовательские исключения требуется создавать только тогда, когда ошибка непосредственно связана с классом, генерирующим эту ошибку (например, пользовательский класс File может генерировать ряд исключений, связанных с доступом к файлам, класс Car может генерировать ряд исключений, связанных с работой автомобиля и т.д.). Тем самым вы обеспечиваете вызывающей стороне возможность обработки множества исключений на основе "индивидуального подхода".
Создание пользовательских исключений, два…
Тип CarIsDeadException переопределяет свойство System.Exception.Message, чтобы установить пользовательское сообщение об ошибке. Однако задачу можно упростить, установив родительское свойство Message через входной параметр конструктора. В результате нам не придется делать ничего, кроме следующего.
public class CarIsDeadException: ApplicationException {
public CarIsDeadException() {}
public CarIsDeadException(string message) : base (message) {}
}
Обратите внимание на то, что теперь мы не определяем строковую переменную для представления сообщения и не переопределяем свойство Message. Вместо этого конструктору базового класса просто передается параметр. В рамках такого подхода пользовательский класс исключений представляет собой немногим большее, чем класс с уникальным именем, полученный из System.ApplicationException без каких бы то ни было членов-переменных (и переопределений базового класса).
Не удивляйтесь, если большинство ваших пользовательских классов исключений (если не все они) будет иметь такой простой вид. Во многих случаях целью создания пользовательского исключения является не функциональные возможности, расширяющие возможности базовых классов, а получение строго именованного типа, идентифицирующего природу возникшей ошибки.
Создание пользовательских исключений, три!
Если вы хотите построить "педантично точный" пользовательский класс исключения, то созданный вами тип должен соответствовать лучшим образцам, использующим исключения .NET. В частности, ваше пользовательское исключение должно подчиняться следующим требованиям:
• быть производным от Exception/ApplicationException;
• обозначаться атрибутом [System.Serializable];
• определять конструктор, используемый по умолчанию;
• определять конструктор, устанавливающий наследуемое свойство Message;
• определять конструктор, обрабатывающий "внутренние исключения";
• определять конструктор, выполняющий сериализацию типа.
Пока что глубина ваших знаний .NET не позволяет вам понять роль атрибутов и сериализации объектов, но сейчас это и не важно. Соответствующие вопросы будут рассмотрены позже. А в завершение обзора, посвященного вопросам создания пользовательских исключений, рассмотрите заключительный вариант CarIsDeadException.
[Serializable]
public class CarIsDeadException: ApplicationException {
public CarIsDeadException() {}
public CarIsDeadException(string message): base (message) {}
public CarIsDeadException(string message, System.Exception inner): base (message, inner) {}
protected CarIsDeadException(System.Runtime.Serialization.SerializationInfо info, System.Runtime.Serialization.StreamingContext context) : base(info, context) {}
}
Пользовательские исключения, соответствующие лучшим образцам программного кода .NET, на самом деле будут отличаться только именами, поэтому вам будет приятно узнать, что в Visual Studio 2005 предлагается шаблон программного кода под названием "Exception" (рис. 6.5), с помощью которого автоматически генерируется новый класс исключения в соответствии с лучшими рекомендациями .NET (шаблоны программного кода обсуждаются в главе 2).
Обработка множеств исключений
В простейшем варианте блок try имеет единственный блок catch. Но на практике часто возникает ситуация, когда операторы в рамках блока try способны создавать множество возможных исключений. Например, представьте себе, что метод Accelerate() дополнительно генерирует определенное библиотекой базовых классов исключение ArgumentOutOfRangeException, когда вы передаете методу недопустимый параметр (мы предполагаем, что недопустимым считается любое значение, меньшее нуля).
// Прежде чем продолжить, проверим допустимость аргумента.
public void Accelerate (int delta) {
if (delta ‹ 0) throw new ArgumentOutOfRangeException("Скорость должна быть выше нуля!");
}
Рис. 6.5. Шаблон программного кода Exception
Логика catch должна соответствовать каждому типу исключений.
static void Main(string [] args) {
…
// Здесь учитывается множество исключений.
try {
for (int i = 0; i ‹ 10; i++) myCar.Accelerate(10);
} catch(CarIsDeadExeeption e) {
// Обработка CarIsDeadException.
} catch (ArgumentOutOfRangeException e) {
// Обработка ArgumentOutOfRangeException.
}
При создании множества блоков catch следует учитывать то, что сгенерированное исключение будет обработано "первым подходящим" бликом catch. Чтобы понять, что такое "первый подходящий" блок catch, добавьте в предыдущий фрагмент программного кода еще один блок catch, который будет обрабатывать все исключения после CarIsDeadException и ArgumentOutOfRangeException, выполняя захват System.Exception общего вида, как показано ниже.
// Этот программный код не компилируется!
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.
}
…
}
Общие операторы catch
В C# также поддерживается "общий" блок catch, который не получает явно объект исключения, генерируемый данным членом.
// Блок catch общего вида.
static void Main(string[] args) {
…
try {
for (int i = 0; i ‹ 10; i++) myCar.Accelerate(10);
} catch {
Console.WriteLine("Случилось что-то ужасное…");
}
…
}
Очевидно, что это не самый информативный способ обработки исключения, поскольку здесь вы не имеете возможности получить содержательную информацию о произошедшей ошибке (например, имя метода, содержимое стека вызовов или пользовательское сообщение). Тем не менее, в C# такая конструкция возможна.
