//.. .
map<int,string> 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<int,defect_reponse *> 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<int,defect_reponse *> 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 () более общей.
// Листинг 7.2. Использование шаблона в функции // importantOperation()
template<class T,class U> int importantOperation(void) {
T ErrorTable; //.. .
U *Solver; //...
Solver = ErrorTable[Result]; Solver->doSomething () ; //...
};
В листинге 7.2 тип ErrorTable не ограничен объекта м и класса defect_response. Этот метод позволяет упростить код обработки ошибок и повысить его гибкость. Здесь демонстрируется использование полиморфизма как по вертикали, так и по горизонтали, что чрезвычайно важно для SPMD- и MPMD-программ. Как упростить программы, реализующие параллелизм с помощью шаблонов и полиморфизма, описано в главе 9. Использование объектов отображения и объектов обработки ошибок — это важнал составляющал повышения надежности ПО. Помимо методов обработки ошибок, мы можем также воспользоваться преимуществами механизма обработки исключительных ситуаций и классов исключений, прелусмотренных в С++ (этому посвящен следующий раздел).
Механизмы обработки исключительных ситуаций в С++
В идеале во время тестирования и отладки должны быть ликвидированы все дефекты протраммы или по крайней мере максимально возможное их количество. Кроме того, следует обработать нежелательные и неудобные условия с использованием обычной программной логики. После устранения всех (или почти всех) дефектов и обработки нежелательных и неудобных условий все остальные «неприятности» попадают в разряд исключительных ситуаций. Обработка исключительных ситуаций в С++ по д держивается с помощью трех ключевых слов: try, throw и catch. Любой код, сталкивающийся сисключительной ситуацией, с которой он не в силах справиться самостоятельно, генерирует исключение «в надежде» на то, что с ней совладает некоторый другой обработчик (расположенный где-то в другом месте программы) (Б. Страуструп, Язык программирования С++ , 1997). Для генерирования объекта некоторого специального типа (типа исключения) используется ключевое слово throw. При этом происходит передача управления обработчику исключения, который предназначен д л я обработки объектов данного типа. Д л я идентификации обработчиков, предназначенных д л я перехвата объектов исключений, используется ключевое слово catch. Рассмотрим пример.
