Камерон Хьюз - Параллельное и распределенное программирование на С++

logic_error Logic(«JIorn4ecKaH ошибка»); throw(Logic);

} catch(const exception &X) {

cout << X.what() « endl;

}

Объекты базового класса exception обладают лишь конструкторами, деструкторами, средствами присваивания, копирования и простейшего вывода отчетной информации. При сбое они не способны его скорректировать. Здесь можно рассчитывать лишь на вывод сообщения об ошибке, возвращаемого методом what() классов исключений. Это сообщение будет определяться строкой, переданной конструктору для объекта класса logic_error. В листинге7.3 переданная конструктору строка «Логическая ошибка» будет возвращена методом what() в catch-блoкe и выведена в виде сообщения.

Семейство классов logic_error выведено из класса exception. И в самом деле, большинство функций классов этого семейства также унаследовано от класса exception. Класс exception содержит метод what() , используемый для уведомления пользователя о возникшей ошибочной ситуации. Каждый класс logic_error-семейства содержит конструктор, используемый для привязки сообщения, специфического для данного конкретного класса. Схема отношений между классами для семейства logic_error показана на рис. 7.5.

Подобно классам семейства runtime_error эти классы также предназначены для последующей специализации. Если пользователь не расширит их функциональность, они не смогут сделать ничего, кроме как уведомить об ошибке и ее типе. Упомянутые выше девять классов исключений общего назначения не обеспечивают никаких действий по корректировке ситуации или обработке ошибок.

Классы исключений можно использовать как есть, т.е. просто для вывода сообщений с описанием происшедших ошибок. Но в качестве метода обработки исключений такой подход практически бесполезен. Просто знать о возникновении исключительной ситуации — не слишком большой шаг на пути повышения надежности ПО. Реальная польза иерархии классов исключений состоит в обеспечении ими архитектурной карты дорог для проектировщика и разработчика. Классы исключений предусматривают основные типы ошибок, которые разработчик может уточнить. Многие исключительные ситуации, которые возникают в среде выполнения, можно было бы отнести к категориям, «охватываемым» семействами классов logic_errorили runtime_error.В качестве примера возьмем класс runtime_errorи продемонстрируем, как можно «сузить» его специализацию. Класс runtime_errorявляется потомком класса exception.Специализацию класса можно определить с помощью механизма наследования. Вот пример:

class file_access_exception : public runtime_error{

protected:

//...

int ErrorNumber;

string DetailedExplanation;

string FileName;

//...

public:

virtual int takeCorrectiveAction(void);

string detailedExplanation(void);

//...

};

Здесь класс file_access_exceptionнаслелует класс runtime_errorи получает специализацию путем добавления нескольких членов данных и функций-членов. В частности, добавляется метод takeCorrectiveAction(). Этот метод можно использовать в качестве вспомогательного средства, с помощью которого обработчик исключений мог бы выполнять работу по коррекции ситуации и восстановлению работоспособности программы. Объект класса file_access_exception«знает», как идентифицировать взаимоблокировку и как ее прекратить. Кроме того, он содержит специализирован н ую логику, предназначенную для борьбы с вирусами, которые могут разрушить файлы, а также специальные средства на случай неожиданного прерывания процесса передачи файлов. Мы можем использовать объекты класса file_access_exceptionвместе со средствами генерирования, перехвата и обработки исключений, прелусмотренными в языке С++. Рассмотрим пример.

try{

//...

fileProcessingOperation();

//.. .

} catch(file_access_exception &E) {

cerr « E.what() << endl;

cerr « E.detailedExplanation() « endl;

E.takeCorrectiveAction();

// Обработчик выполняет дополнительные действия

// по корректировке ситуации.

//.. .

}

Этот метод позволяет создать объекты отображения ExceptionTable,подобные объектам отображения ErrorTableиз л истингов 7.1 и 7.2. При этом код обработчика исключений можно упростить за счет испо л ьзования вертикального и горизонтального полиморфизма.

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

// Объявление класса исключения.

class exception {

public:

exception() throw() {}

exception(const exception&) throw() {}

exception& operator=(const exception&) throw() {return *this;}

virtual ~exception() throw() {}

virtual const char* what() const throw();

};

Обратите внимание на отсутствие аргументов в объявлениях throw() -методов. Пустые аргументы означают, что данный метод не может сгенерировать исключение [12]. Если он попытается это сделать, во время компиляции будет выдано сообщение об ошибке. Если базовый класс не может сгенерировать исключение, то соответствующий метод в любом производном классе также не сделает этого.

Обработку исключительных ситуаций необходимо использовать в качестве «последней линии обороны», поскольку ее механизм в корне меняет естественную передачу управления в программе. Существуют схемы, которые пытаются замаскировать этот факт, но эти схемы обычно не характеризуются гибкостью, достаточной для программ, реализующих методы параллелизма или распределения. В подавляющем большинстве ситуаций, в которых есть соблазн использовать обработчики, перехватывающие абсолютно все исключения, программную логику можно сделать более ошибкоустойчивой с помощью ее усовершенствования или жесткой обработки ошибок. Для облегчения идентификации ко м понентов систе м ы, которые критичны для приемлемого завершения ПО. часто испо л ьзуютс я диаграммы событий. Диаграммы событий помогают понять, какие компоненты потенциально не опасны (и их можно не принимать во внимание), а какие могут привести к отказу системы. В некоторых приложениях отказ одного компонента необязательно приводит к отказу всей системы. Для обеспечения безотказной работы системы в тех случаях, когда отказ одного компонента таки приводит к отказу системы в целом, методы обработки исключений можно использовать в сочетании с методами обработки ошибок. Пример простой диаграммы событий показан на рис. 7.6.