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

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

Компонент отображения (map)можно использовать как составную часть стратегии обработки ошибок или обработки исключений. Назначение отображения — связать один элемент с другим. Например, отображение можно использовать для связи номеров ошибок с их описаниями:

//.. .

map ErrorTable;

ErrorTable[123] = «Деление на нуль»;

ErrorTable[4556] = «Отсутствие тонального вызова»;

//. . .

Здесь число 123 связано с описанием «Деление на нуль». Тогда при выполнении инструкции

cout « ErrorTable[123] « endl;

в объект выходного потока cout будет записана строка «Деление на нуль».

Помимо отображения встроенных типов данных, можно также отображать (т.е. находить соответствие) определенные пользователем объекты, содержащие данные встроенных типов. Вместо того, чтобы некоторое отображение просто возвращало описательное сообщение для каждого номера ошибки, можно позаботиться о том, чтобы оно возвращало объект с соответствующим номером ошибки. Этот объект может иметь методы, предназначенные для коррекции ошибок, составления отчетов об ошибках и их регистрации (записи ошибок в системный журнал). Например, предположим, что у нас есть следующий определенный пользователем объект:

defect_response:

class defect_response{

protected: //. . .

int DefectNo;

string Explanation;

public:

bool operator<(defect_response &X);

virtual int doSomething(void); string explanation(void);

//...

};

Теперь мы можем внести в отображение объекты типа defect_response:

//...

map ErrorTable;

defect_response * Response;

Response = new defect_response;

ErrorTable[123] = Response;

//...

Этот код связывает объект отклика (на ошибку) с номером ошибки 123. Благодаря полиморфизму объект отображения может содержать указатели на любой объект типа defect_responseили любой объект, который выведен из него. Предположим, что у нас есть следующий класс:

class exception_response : public defect_response{

//.. . public:

int doSomething(void)

//...

};

Этот класс exception_responseявляется потомко м класса defect_response,поэтому мы можем внести в объект ErrorTableуказатели на тип exception_re sponse.

//...

map ErrorTable;

defect_response * Response;

exception_response *Response2;

Response = new defect_response;

Respone2 = new exception_response;

ErrorTable[123] = Response; // Хранит объект типа

// defect_response.

ErrorTable[456] = Response2; // Хранит объект типа

// exception_response.

//...

Это определение означает, что объект типа ErrorTableможет связывать с соответствующим но м ером ошибки различные объекты (с различными описаниями и характеристиками). Следовательно, при вызове метода doSomething()объект ProblemSolverбудет выполнять различные наборы инструкций:

//...

defect_response *ProblemSolver;

ProblemSovler = ErrorTable[123];

ProblemSolver->doSomething();

ProblemSovler = ErrorTable[456];

ProblemSovler->doSomething();

//...

Несмотря на то что Переменная ProblemSolverпредставляет собой указатель на объект defect_response,полиморфизм позволяет этой переменной указывать на объект типа exception_response или любой другой объект, выведенный из класса defect_response. Поскольку метод doSomething () объявлен виртуальным в классе defect_response, компилятор может выполнить динамическое связывание. Это дает гарантию корректного вызова метода doSomething() при выполнении приложения. Именно динамическое связывание позволяет каждому потомку класса defect_response определить собственный метод doSomething (). Нам нужно, чтобы вызов метода doSomething() зависел от того, ссылка на какой именно потомок класса defect_response используется при этом. Рассматриваемый метод позволяет связывать номера ошибок с объектами, имеющими отношение к обработке определенных сбойных ситуаций. С помощью этого метода можно значительно упростить код обработки ошибок. В листинге 7.1, например, показано, как значение, возвращаемое некоторой функцией, можно использовать для выбора соответствующего объекта обработки ошибок.

// Листинг 7.1. Использование значений, возвращаемых

// функцией, для определения корректного

// объекта типа ErrorHandler

void importantOperation(void) {

//. . .

Result = reliableOperation(); if(Result != Success){

defect_response *Solver;

Solver = ErrorTable[Result];

Solver->doSomething();

}

else{

// Продолжение обработки.

}

// . . .

}

В листинге 7.1 обратите внимание на то, что мы не используем последовательность if- или case-инструкций. Объект отображения позволяет получить непосредственный доступ к желаемому объекту обработки ошибок по индексу. Конкретный метод doSomething(), вызываемый в листинге 7.1, зависит от значения переменной Result. Безусловно, данный пример демонстрирует упрощенную схему обработки ошибочных ситуаций. Так, например, в листинге 7.1 не показано, кто (или что) отвечает за управление динамически выделяемой памятью для объектов, хранимых в отображении ErrorTable. Кроме того, здесь не учтено, что функции reliableOperation() и doSomething() могут выполниться неудачно. Поэтому реальный код будет, конечно же, несколько сложнее, чем тот, что приведен в листингe 7.1. Но все же этот пример ясно показывает, как одним «ударом» обработать множество ситуаций сбоя. Мы можем пойти еще дальше. В листинге 7.1 предполагается, что все возможные ошибки будут охвачены объектами типа ErrorTable. Все ErrorTable-объекты представляют собой либо объекты типа defect_response, либо объекты, выведенные из класса defect_response. А что, если у нас будет несколько семейств классов обработки ошибок? В листинге 7.2 показано, как с помощью шаблонов сделать функцию importantOperation () более общей.