Параллельное и распределенное программирование на С++

Хьюз Камерон

// Листинг 7.3. Генерирование объекта класса exception и

// объекта класса logic_error

try{

exception X; throw(X) ;

} catch(const exception &X) {

cout « X.what << endl;

}

try{

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

Семейство

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

Рис. 7.5. Схема отношений между классами для семейства классов logic_error

Подобно классам семейства 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.

Illustration 1: Рис. Рис. 7.6 Простая диаграмма событий

Мы используем диаграммы событий для построения схемы действия обработчика исключительных сигуаций. На рис. 7.6 схематично изображена система, состоящая из семи задач, помеченных буквами А, В, С, D, E, F и H. Обратите внимание на то, что каждая метка (обозначающал задачу) расположена над переключателем. Если переключатели закрыты, компонент функционирует, в противном случае — нет. Крайняя точка слева представляет начало, а крайняя точка справа — конец выполнения. Для успешного завершения программы необходимо найти путь через действующие компоненты. Попробуем продемонстрировать, как применить эгу диаграмму к нашему случаю обработки исключений. Предположим, что мы начинаем программу с выполнения задачи А. Чтобы успешно завершить программу, необходимо корректно решить обе задачи А и С. На языке диаграммы это означает, что переключатели А и С должны быть закрыты. На нашей диаграмме событий переключатели А и С находятся на одной ветви, что свидетельствует об их параллельном выполнении. Если произойдет отказ в любой из этих задач (А или С), будет сгенерировано исключение. Обработчик исключений мог бы снова начать выполнение задач А и С. Однако анализ нашей диаграммы событий показывает, что завершение всей программы будет успешным, если успешным будет выполнение либо ветви АС, либо ветви DE, либо ветви FBH. Поэтому мы проектируем наш обработчик исключений таким образом, чтобы он выполнял один из альтернативных наборов компонентов (например, DE или FBH). Наборы компонентов (AC, DE и FBH) связаны между собой отношением ИЛИ. Это значит, что к успешному завершению программы приведет успешное выполнение любого набора параллельно выполняемых компонентов. Таким образом, простая диаграмма событий (см. рис. 7.6) позволяет понять, как следует построить обработчик исключений. Выражение