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

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.