Страница:
void g()
{
try {
// какие-то другие операторы
}
catch (file_system_err) {
// ...
}
}
Это важный момент, поскольку такой системный сервис как работа в
сети должен быть прозрачен, а это означает, что создатель функции
g() может даже и не знать, что эта функция будет выполняться
в сетевом режиме.
Отметим, что в настоящее время нет стандартного множества
особых ситуаций для стандартной математической библиотеки и
библиотеки ввода-вывода. Задача комитетов ANSI и ISO по стандартизации
С++ решить нужно ли такое множество и какие в нем следует использовать
имена и классы.
Поскольку можно сразу перехватить все особые ситуации
(см. $$9.3.2), нет настоятельной необходимости создавать для этой
цели общий, базовый для всех особых ситуаций, класс. Однако, если
все особые ситуации являются производными от пустого класса
Exception (особая ситуация), то в интерфейсах их использование
становится более регулярным (см. $$9.6). Если вы используете общий
базовый класс Exception, убедитесь, что в нем ничего нет кроме
виртуального деструктора. В противном случае такой класс может
вступить в противоречие с предполагаемым стандартом.
Если для обработки особых ситуаций мы используем иерархию классов,
то, естественно, каждый обработчик должен разбираться только с
частью информации, передаваемой при особых ситуациях. Можно сказать,
что, как правило, особая ситуация перехватывается обработчиком
ее базового класса, а не обработчиком класса, соответствующего
именно этой особой ситуации. Именование и перехват обработчиком особой
ситуации семантически эквивалентно именованию и получению параметра
в функции. Проще говоря, формальный параметр инициализируется
значением фактического параметра. Это означает, что запущенная
особая ситуация "низводится" до особой ситуации, ожидаемой
обработчиком. Например:
class Matherr {
// ...
virtual void debug_print();
};
class Int_overflow : public Matherr {
public:
char* op;
int opr1, opr2;;
int_overflow(const char* p, int a, int b)
{ cerr << op << '(' << opr1 << ',' << opr2 << ')'; }
};
void f()
{
try {
g();
}
catch (Matherr m) {
// ...
}
}
При входе в обработчик Matherr особая ситуация m является объектом
Matherr, даже если при обращении к g() была запущена Int_overflow.
Это означает, что дополнительная информация, передаваемая в
Int_overflow, недоступна.
Как обычно, чтобы иметь доступ к дополнительной информации можно
использовать указатели или ссылки. Поэтому можно было написать так:
int add(int x, int y) // сложить x и y с контролем
{
if (x > 0 && y > 0 && x > MAXINT - y
|| x < 0 && y < 0 && x < MININT + y)
throw Int_overflow("+", x, y);
// Сюда мы попадаем, либо когда проверка
// на переполнение дала отрицательный результат,
// либо когда x и y имеют разные знаки
return x + y;
}
void f()
{
try {
add(1,2);
add(MAXINT,-2);
add(MAXINT,2); // а дальше - переполнение
}
catch (Matherr& m) {
// ...
m.debug_print();
}
}
Здесь последнее обращение к add приведет к запуску особой ситуации,
который, в свою очередь, приведет к вызову Int_overflow::debug_print().
Если бы особая ситуация передавалась по значению, а не по ссылке, то
была бы вызвана функция Matherr::debug_print().
Нередко бывает так, что перехватив особую ситуацию, обработчик
решает, что с этой ошибкой он ничего не сможет поделать. В таком
случае самое естественное запустить особую ситуацию снова в надежде,
что с ней сумеет разобраться другой обработчик:
void h()
{
try {
// какие-то операторы
}
catch (Matherr) {
if (can_handle_it) { // если обработка возможна,
// сделать ее
}
else {
throw; // повторный запуск перехваченной
// особой ситуации
}
}
}
Повторный запуск записывается как оператор throw без параметров.
При этом снова запускается исходная особая ситуация, которая была
перехвачена, а не та ее часть, на которую рассчитан обработчик
Matherr. Иными словами, если была запущена Int_overflow, вызывающая
h() функция могла бы перехватить ее как Int_overflow, несмотря на
то, что она была перехвачена в h() как Matherr и запущена снова:
void k()
{
try {
h();
// ...
}
catch (Int_overflow) {
// ...
}
}
Полезен вырожденный случай перезапуска. Как и для функций,
эллипсис ... для обработчика означает "любой параметр", поэтому
оператор catch (...) означает перехват любой особой ситуации:
void m()
{
try {
// какие-то операторы
}
catch (...) {
// привести все в порядок
throw;
}
}
Этот пример надо понимать так: если при выполнении основной части
m() возникает особая ситуация, выполняется обработчик, которые
выполняет общие действия по устранению последствий особой ситуации,
после этих действий особая ситуация, вызвавшая их, запускается
повторно.
Поскольку обработчик может перехватить производные особые ситуации
нескольких типов, порядок, в котором идут обработчики в проверяемом
блоке, существенен. Обработчики пытаются перехватить особую
ситуацию в порядке их описания. Приведем пример:
try {
// ...
}
catch (ibuf) {
// обработка переполнения буфера ввода
}
catch (io) {
// обработка любой ошибки ввода-вывода
}
catch (stdlib) {
// обработка любой особой ситуации в библиотеке
}
catch (...) {
// обработка всех остальных особых ситуаций
}
Тип особой ситуации в обработчике соответствует типу запущенной
особой ситуации в следующих случаях: если эти типы совпадают, или
второй тип является типом доступного базового класса запущенной ситуации,
или он является указателем на такой класс, а тип ожидаемой ситуации
тоже указатель ($$R.4.6).
Поскольку транслятору известна иерархия классов, он способен
обнаружить такие нелепые ошибки, когда обработчик catch (...) указан
не последним, или когда обработчик ситуации базового класса
предшествует обработчику производной от этого класса ситуации
($$R15.4). В обоих случая, последующий обработчик (или обработчики)
не могут быть запущены, поскольку они "маскируются" первым
обработчиком.
Если в некоторой функции потребуются определенные ресурсы, например,
нужно открыть файл, отвести блок памяти в области свободной
памяти, установить монопольные права доступа и т.д., для дальнейшей
работы системы обычно бывает крайне важно, чтобы ресурсы были
освобождены надлежащим образом. Обычно такой "надлежащий способ"
реализует функция, в которой происходит запрос ресурсов и освобождение
их перед выходом. Например:
void use_file(const char* fn)
{
FILE* f = fopen(fn,"w");
// работаем с f
fclose(f);
}
Все это выглядит вполне нормально до тех пор, пока вы не поймете,
что при любой ошибке, происшедшей после вызова fopen() и до вызова
fclose(), возникнет особая ситуация, в результате которой мы
выйдем из use_file(), не обращаясь к fclose().Ь
Ь Стоит сказать, что та же проблема возникает и в языках, не
поддерживающих особые ситуации. Так, обращение к функции longjump()
из стандартной библиотеки С может иметь такие же неприятные
последствия.
Если вы создаете устойчивую к ошибкам системам, эту проблему
придется решать. Можно дать примитивное решение:
void use_file(const char* fn)
{
FILE* f = fopen(fn,"w");
try {
// работаем с f
}
catch (...) {
fclose(f);
throw;
}
fclose(f);
}
Вся часть функции, работающая с файлом f, помещена в проверяемый
блок, в котором перехватываются все особые ситуации, закрывается
файл и особая ситуация запускается повторно.
Недостаток этого решения в его многословности, громоздкости
и потенциальной расточительности. К тому же всякое многословное
и громоздкое решение чревато ошибками, хотя бы в силу усталости
программиста. К счастью, есть более приемлемое решение. В общем
виде проблему можно сформулировать так:
void acquire()
{
// запрос ресурса 1
// ...
// запрос ресурса n
// использование ресурсов
// освобождение ресурса n
// ...
// освобождение ресурса 1
}
Как правило бывает важно, чтобы ресурсы освобождались в обратном
по сравнению с запросами порядке. Это очень сильно напоминает порядок
работы с локальными объектами, создаваемыми конструкторами и
уничтожаемыми деструкторами. Поэтому мы можем решить проблему запроса и
освобождения ресурсов, если будем использовать подходящие объекты
классов с конструкторами и деструкторами. Например, можно определить
класс FilePtr, который выступает как тип FILE* :
class FilePtr {
FILE* p;
public:
FilePtr(const char* n, const char* a)
{ p = fopen(n,a); }
FilePtr(FILE* pp) { p = pp; }
~FilePtr() { fclose(p); }
operator FILE*() { return p; }
};
Построить объект FilePtr можно либо, имея объект типа FILE*, либо,
получив нужные для fopen() параметры. В любом случае этот
объект будет уничтожен при выходе из его области видимости, и
его деструктор закроет файл. Теперь наш пример сжимается до такой
функции:
void use_file(const char* fn)
{
FilePtr f(fn,"w");
// работаем с f
}
Деструктор будет вызываться независимо от того, закончилась ли функция
нормально, или произошел запуск особой ситуации.
Описанный способ управления ресурсами обычно называют "запрос ресурсов
путем инициализации". Это универсальный прием, рассчитанный на
свойства конструкторов и деструкторов и их взаимодействие с
механизмом особых ситуаций.
Объект не считается построенным, пока не завершил выполнение его
конструктор. Только после этого возможна раскрутка стека,
сопровождающая вызов деструктора объекта. Объект, состоящий из
вложенных объектов, построен в той степени, в какой построены
вложенные объекты.
Хорошо написанный конструктор должен гарантировать, что объект
построен полностью и правильно. Если ему не удается сделать это,
он должен, насколько это возможно, восстановить состояние системы,
которое было до начала построения. Для простых конструкторов было бы
идеально всегда удовлетворять хотя бы одному условию - правильности
или законченности объектов, и никогда не оставлять объект
в "наполовину построенном" состоянии. Этого можно добиться, если
применять при построении членов способ "запроса ресурсов путем
инициализации".
Рассмотрим класс X, конструктору которого требуется два ресурса:
файл x и замок y (т.е. монопольные права доступа к чему-либо).
Эти запросы могут быть отклонены и привести к запуску особой
ситуации. Чтобы не усложнять работу программиста, можно потребовать,
чтобы конструктор класса X никогда не завершался тем, что запрос на
файл удовлетворен, а на замок нет. Для представления двух видов
ресурсов мы будем использовать объекты двух классов FilePtr и
LockPtr (естественно, было бы достаточно одного класса, если x и y
ресурсы одного вида). Запрос ресурса выглядит как инициализация
представляющего ресурс объекта:
class X {
FilePtr aa;
LockPtr bb;
// ...
X(const char* x, const char* y)
: aa(x), // запрос `x'
bb(y) // запрос `y'
{ }
// ...
};
Теперь, как это было для случая локальных объектов, всю служебную
работу, связанную с ресурсами, можно возложить на реализацию.
Пользователь не обязан следить за ходом такой работой. Например,
если после построения aa и до построения bb возникнет особая
ситуация, то будет вызван только деструктор aa, но не bb.
Это означает, что если строго придерживаться этой простой
схемы запроса ресурсов, то все будет в порядке. Еще более важно
то, что создателю конструктора не нужно самому писать обработчики
особых ситуаций.
Для требований выделить блок в свободной памяти характерен самый
произвольный порядок запроса ресурсов. Примеры таких запросов уже
неоднократно встречались в этой книге:
class X {
int* p;
// ...
public:
X(int s) { p = new int[s]; init(); }
~X() { delete[] p; }
// ...
};
Это типичный пример использования свободной памяти, но в совокупности с
особыми ситуациями он может привести к ее исчерпанию памяти.
Действительно, если в init() запущена особая ситуация, то отведенная
память не будет освобождена. Деструктор не будет вызываться, поскольку
построение объекта не было завершено. Есть более надежный вариант
этого примера:
template<class T> class MemPtr {
public:
T* p;
MemPtr(size_t s) { p = new T[s]; }
~MemPtr() { delete[] p; }
operator T*() { return p; }
}
class X {
MemPtr<int> cp;
// ...
public:
X(int s):cp(s) { init(); }
// ...
};
Теперь уничтожение массива, на который указывает p, происходит неявно
в MemPtr. Если init() запустит особую ситуацию, отведенная память
будет освобождена при неявном вызове деструктора для полностью
построенного вложенного объекта cp.
Отметим также, что стандартная стратегия выделения памяти в С++
гарантирует, что если функции operator new() не удалось выделить память
для объекта, то конструктор для него никогда не будет вызываться. Это
означает, что пользователю не надо опасаться, что конструктор или
деструктор может быть вызван для несуществующего объекта.
Теоретически дополнительные расходы, требующиеся для обработки
особых ситуаций, когда на самом деле ни одна из них не возникла, могут
быть сведены к нулю. Однако, вряд ли это верно для ранних
реализациях языка. Поэтому будет разумно в критичных внутренних циклах
программы пока не использовать локальные переменные классов
с деструкторами.
Не все программы должны быть устойчивы ко всем видам ошибок. Не все
ресурсы являются настолько критичными, чтобы оправдать попытки
защитить их с помощью описанного способа "запроса ресурсов путем
инициализации". Есть множество программ, которые просто читают
входные данные и выполняются до конца. Для них самой подходящей
реакцией на динамическую ошибку будет просто прекращение счета
(после выдачи соответствующего сообщения). Освобождение всех
затребованных ресурсов возлагается на систему, а пользователь
должен произвести повторный запуск программы с более подходящими
входными данными. Наша схема предназначена для задач, в которых
такая примитивная реакция на динамическую ошибку неприемлема.
Например, разработчик библиотеки обычно не в праве делать допущения
о том, насколько устойчива к ошибкам, должна быть программа,
работающая с библиотекой. Поэтому он должен учитывать все динамические
ошибки и освобождать все ресурсы до возврата из библиотечной функции
в пользовательскую программу. Метод "запроса ресурсов путем
инициализации" в совокупности с особыми ситуациями, сигнализирующими
об ошибке, может пригодиться при создании многих библиотек.
Есть одна из вечных проблем программирования: что делать, если не
удалось удовлетворить запрос на ресурс? Например, в предыдущем
примере мы спокойно открывали с помощью fopen() файлы и запрашивали с
помощью операции new блок свободной памяти, не задумываясь при этом,
что такого файла может не быть, а свободная память может исчерпаться.
Для решения такого рода проблем у программистов есть два способа:
Повторный запрос: пользователь должен изменить свой запрос и
повторить его.
Завершение: запросить дополнительные ресурсы от системы, если
их нет, запустить особую ситуацию.
Первый способ предполагает для задания приемлемого запроса
содействие пользователя, во втором пользователь должен быть готов
правильно отреагировать на отказ в выделении ресурсов. В большинстве
случаев последний способ намного проще и позволяет поддерживать в
системе разделение различных уровней абстракции.
В С++ первый способ поддержан механизмом вызова функций, а
второй - механизмом особых ситуаций. Оба способа можно
продемонстрировать на примере реализации и использования операции
new:
#include <stdlib.h>
extern void* _last_allocation;
extern void* operator new(size_t size)
{
void* p;
while ( (p=malloc(size))==0 ) {
if (_new_handler)
(*_new_handler)(); // обратимся за помощью
else
return 0;
}
return _last_allocation=p;
}
Если операция new() не может найти свободной памяти, она обращается
к управляющей функции _new_handler(). Если в _new_handler() можно
выделить достаточный объем памяти, все нормально. Если нет, из
управляющей функции нельзя возвратиться в операцию new, т.к.
возникнет бесконечный цикл. Поэтому управляющая функция может
запустить особую ситуацию и предоставить исправлять положение
программе, обратившейся к new:
void my_new_handler()
{
try_find_some_memory(); // попытаемся найти
// свободную память
if (found_some()) return; // если она найдена, все в порядке
throw Memory_exhausted(); // иначе запускаем особую
// ситуацию "Исчерпание_памяти"
}
Где-то в программе должен быть проверяемый блок с соответствующим
обработчиком:
try {
// ...
}
catch (Memory_exhausted) {
// ...
}
В функции operator new() использовался указатель на управляющую
функцию _new_handler, который настраивается стандартной функцией
set_new_handler(). Если нужно настроиться на собственную управляющую
функцию, надо обратиться так
set_new_handler(&my_new_handler);
Перехватить ситуацию Memory_exhausted можно следующим образом:
void (*oldnh)() = set_new_handler(&my_new_handler);
try {
// ...
}
catch (Memory_exhausted) {
// ...
}
catch (...) {
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
throw(); // повторный запуск особой ситуации
}
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
Можно поступить еще лучше, если к управляющей функции применить
описанный в $$9.4 метод "запроса ресурсов путем инициализации" и
убрать обработчик catch (...).
В решении, использующим my_new_handler(), от точки обнаружения
ошибки до функции, в которой она обрабатывается, не передается
никакой информации. Если нужно передать какие-то данные, то
пользователь может включить свою управляющую функцию в класс.
Тогда в функции, обнаружившей ошибку, нужные данные можно поместить в
объект этого класса. Подобный способ, использующий объекты-функции,
применялся в $$10.4.2 для реализации манипуляторов. Способ, в
котором используется указатель на функцию или объект-функция для
того, чтобы из управляющей функции, обслуживающей некоторый ресурс,
произвести "обратный вызов" функции запросившей этот ресурс,
обычно называется просто обратным вызовом (callback).
При этом нужно понимать, что чем больше информации передается
из обнаружившей ошибку функции в функцию, пытающуюся ее исправить,
тем больше зависимость между этими двумя функциями. В общем случае
лучше сводить к минимуму такие зависимости, поскольку всякое
изменение в одной из функций придется делать с учетом другой функцией,
а, возможно, ее тоже придется изменять. Вообще, лучше не смешивать
отдельные компоненты программы. Механизм особых ситуаций позволяет
сохранять раздельность компонентов лучше, чем обычный механизм вызова
управляющих функций, которые задает функция, затребовавшая ресурс.
В общем случае разумный подход состоит в том, чтобы выделение
ресурсов было многоуровневым (в соответствии с уровнями абстракции).
При этом нужно избегать того, чтобы функции одного уровня зависели
от управляющей функции, вызываемой на другом уровне. Опыт создания
больших программных систем показывает, что со временем удачные
системы развиваются именно в этом направлении.
Особые ситуации дают средство сигнализировать о происходящих в
конструкторе ошибках. Поскольку конструктор не возвращает такое
значение, которое могла бы проверить вызывающая функция, есть
следующие обычные (т.е. не использующие особые ситуации) способы
сигнализации:
[1] Возвратить объект в ненормальном состоянии в расчете,
что пользователь проверит его состояние.
[2] Установить значение нелокальной переменной, которое
сигнализирует, что создать объект не удалось.
Особые ситуации позволяют тот факт, что создать объект не удалось,
передать из конструктора вовне:
Vector::Vector(int size)
{
if (sz<0 || max<sz) throw Size();
// ...
}
В функции, создающей вектора, можно перехватить ошибки, вызванные
недопустимым размером (Size()) и попытаться на них отреагировать:
Vector* f(int i)
{
Vector* p;
try {
p = new Vector v(i);
}
catch (Vector::Size) {
// реакция на недопустимый размер вектора
}
// ...
return p;
}
Управляющая созданием вектора функция способна правильно
отреагировать на ошибку. В самом обработчике особой ситуации можно
применить какой-нибудь из стандартных способов диагностики и
восстановления после ошибки. При каждом перехвате особой ситуации
в управляющей функции может быть свой взгляд на причину ошибки. Если
с каждой особой ситуацией передаются описывающие ее данные, то объем
данных, которые нужно анализировать для каждой ошибки, растет. Основная
задача обработки ошибок в том, чтобы обеспечить надежный и удобный
способ передачи данных от исходной точки обнаружения ошибки до того
места, где после нее возможно осмысленное восстановление.
Способ "запроса ресурсов путем инициализации" - самый надежное
и красивое решение в том случае, когда имеются конструкторы, требующие
более одного ресурса. По сути он позволяет свести задачу выделения
нескольких ресурсов к повторно применяемому, более простому, способу,
рассчитанному на один ресурс.
Если особая ситуация ожидалась, была перехвачена и не оказала
плохого воздействия на ход программы, то стоит ли ее называть
ошибкой? Так говорят только потому, что программист думает о ней
как об ошибке, а механизм особых ситуаций является средством
обработки ошибок. С другой стороны, особые ситуации можно
рассматривать просто как еще одну структуру управления. Подтвердим
это примером:
class message { /* ... */ }; // сообщение
class queue { // очередь
// ...
message* get(); // вернуть 0, если очередь пуста
// ...
};
void f1(queue& q)
{
message* m = q.get();
if (m == 0) { // очередь пуста
// ...
}
// используем m
}
Этот пример можно записать так:
class Empty { } // тип особой ситуации "Пустая_очередь"
class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
// ...
};
void f2(queue& q)
{
try {
message* m = q.get();
// используем m
}
catch (Empty) { // очередь пуста
// ...
}
}
В варианте с особой ситуацией есть даже какая-то прелесть. Это
хороший пример того, когда трудно сказать, можно ли считать
такую ситуацию ошибкой. Если очередь не должна быть пустой
(т.е. она бывает пустой очень редко, скажем один раз из тысячи),
и действия в случае пустой очереди можно рассматривать как
восстановление, то в функции f2() взгляд на особую ситуацию будет
такой, которого мы до сих пор и придерживались (т.е. обработка особых
ситуаций есть обработка ошибок). Если очередь часто бывает пустой,
а принимаемые в этом случае действия образуют одну из ветвей
нормального хода программы, то придется отказаться от такого взгляда
на особую ситуацию, а функцию f2() надо переписать:
class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
int empty();
// ...
};
void f3(queue& q)
{
if (q.empty()) { // очередь пуста
// ...
}
else {
message* m = q.get();
// используем m
}
}
Отметим, что вынести из функции get() проверку очереди на пустоту
можно только при условии, что к очереди нет параллельных обращений.
Не так то просто отказаться от взгляда, что обработка особой
ситуации есть обработка ошибки. Пока мы придерживаемся такой точки
зрения, программа четко подразделяется на две части: обычная часть
и часть обработки ошибок. Такая программа более понятна. К сожалению,
в реальных задачах провести четкое разделение невозможно, поэтому
структура программы должна (и будет) отражать этот факт. Допустим,
очередь бывает пустой только один раз (так может быть, если функция
get() используется в цикле, и пустота очереди говорит о конце цикла).
Тогда пустота очереди не является чем-то странным или ошибочным.
Поэтому, используя для обозначения конца очереди особую ситуацию,
мы расширяем представление об особых ситуациях как ошибках. С другой
стороны, действия, принимаемые в случае пустой очереди, явно отличаются
от действий, принимаемых в ходе цикла (т.е. в обычном случае).
Механизм особых ситуаций является менее структурированным,
чем такие локальные структуры управления как операторы if или for.
Обычно он к тому же является не столь эффективным, если особая
ситуация действительно возникла. Поэтому особые ситуации следует
использовать только в том случае, когда нет хорошего решения с более
традиционными управляющими структурами, или оно, вообще, невозможно.
Например, в случае пустой очереди можно прекрасно использовать для
сигнализации об этом значение, а именно нулевое значение указателя на
строку message, значит особая ситуация здесь не нужна. Однако, если бы
из класса queue мы получали вместо указателя значение типа int, то
то могло не найтись такого значения, обозначающего пустую очередь.
В таком случае функция get() становится эквивалентной операции
индексации из $$9.1, и более привлекательно представлять пустую очередь
{
try {
// какие-то другие операторы
}
catch (file_system_err) {
// ...
}
}
Это важный момент, поскольку такой системный сервис как работа в
сети должен быть прозрачен, а это означает, что создатель функции
g() может даже и не знать, что эта функция будет выполняться
в сетевом режиме.
Отметим, что в настоящее время нет стандартного множества
особых ситуаций для стандартной математической библиотеки и
библиотеки ввода-вывода. Задача комитетов ANSI и ISO по стандартизации
С++ решить нужно ли такое множество и какие в нем следует использовать
имена и классы.
Поскольку можно сразу перехватить все особые ситуации
(см. $$9.3.2), нет настоятельной необходимости создавать для этой
цели общий, базовый для всех особых ситуаций, класс. Однако, если
все особые ситуации являются производными от пустого класса
Exception (особая ситуация), то в интерфейсах их использование
становится более регулярным (см. $$9.6). Если вы используете общий
базовый класс Exception, убедитесь, что в нем ничего нет кроме
виртуального деструктора. В противном случае такой класс может
вступить в противоречие с предполагаемым стандартом.
Если для обработки особых ситуаций мы используем иерархию классов,
то, естественно, каждый обработчик должен разбираться только с
частью информации, передаваемой при особых ситуациях. Можно сказать,
что, как правило, особая ситуация перехватывается обработчиком
ее базового класса, а не обработчиком класса, соответствующего
именно этой особой ситуации. Именование и перехват обработчиком особой
ситуации семантически эквивалентно именованию и получению параметра
в функции. Проще говоря, формальный параметр инициализируется
значением фактического параметра. Это означает, что запущенная
особая ситуация "низводится" до особой ситуации, ожидаемой
обработчиком. Например:
class Matherr {
// ...
virtual void debug_print();
};
class Int_overflow : public Matherr {
public:
char* op;
int opr1, opr2;;
int_overflow(const char* p, int a, int b)
{ cerr << op << '(' << opr1 << ',' << opr2 << ')'; }
};
void f()
{
try {
g();
}
catch (Matherr m) {
// ...
}
}
При входе в обработчик Matherr особая ситуация m является объектом
Matherr, даже если при обращении к g() была запущена Int_overflow.
Это означает, что дополнительная информация, передаваемая в
Int_overflow, недоступна.
Как обычно, чтобы иметь доступ к дополнительной информации можно
использовать указатели или ссылки. Поэтому можно было написать так:
int add(int x, int y) // сложить x и y с контролем
{
if (x > 0 && y > 0 && x > MAXINT - y
|| x < 0 && y < 0 && x < MININT + y)
throw Int_overflow("+", x, y);
// Сюда мы попадаем, либо когда проверка
// на переполнение дала отрицательный результат,
// либо когда x и y имеют разные знаки
return x + y;
}
void f()
{
try {
add(1,2);
add(MAXINT,-2);
add(MAXINT,2); // а дальше - переполнение
}
catch (Matherr& m) {
// ...
m.debug_print();
}
}
Здесь последнее обращение к add приведет к запуску особой ситуации,
который, в свою очередь, приведет к вызову Int_overflow::debug_print().
Если бы особая ситуация передавалась по значению, а не по ссылке, то
была бы вызвана функция Matherr::debug_print().
Нередко бывает так, что перехватив особую ситуацию, обработчик
решает, что с этой ошибкой он ничего не сможет поделать. В таком
случае самое естественное запустить особую ситуацию снова в надежде,
что с ней сумеет разобраться другой обработчик:
void h()
{
try {
// какие-то операторы
}
catch (Matherr) {
if (can_handle_it) { // если обработка возможна,
// сделать ее
}
else {
throw; // повторный запуск перехваченной
// особой ситуации
}
}
}
Повторный запуск записывается как оператор throw без параметров.
При этом снова запускается исходная особая ситуация, которая была
перехвачена, а не та ее часть, на которую рассчитан обработчик
Matherr. Иными словами, если была запущена Int_overflow, вызывающая
h() функция могла бы перехватить ее как Int_overflow, несмотря на
то, что она была перехвачена в h() как Matherr и запущена снова:
void k()
{
try {
h();
// ...
}
catch (Int_overflow) {
// ...
}
}
Полезен вырожденный случай перезапуска. Как и для функций,
эллипсис ... для обработчика означает "любой параметр", поэтому
оператор catch (...) означает перехват любой особой ситуации:
void m()
{
try {
// какие-то операторы
}
catch (...) {
// привести все в порядок
throw;
}
}
Этот пример надо понимать так: если при выполнении основной части
m() возникает особая ситуация, выполняется обработчик, которые
выполняет общие действия по устранению последствий особой ситуации,
после этих действий особая ситуация, вызвавшая их, запускается
повторно.
Поскольку обработчик может перехватить производные особые ситуации
нескольких типов, порядок, в котором идут обработчики в проверяемом
блоке, существенен. Обработчики пытаются перехватить особую
ситуацию в порядке их описания. Приведем пример:
try {
// ...
}
catch (ibuf) {
// обработка переполнения буфера ввода
}
catch (io) {
// обработка любой ошибки ввода-вывода
}
catch (stdlib) {
// обработка любой особой ситуации в библиотеке
}
catch (...) {
// обработка всех остальных особых ситуаций
}
Тип особой ситуации в обработчике соответствует типу запущенной
особой ситуации в следующих случаях: если эти типы совпадают, или
второй тип является типом доступного базового класса запущенной ситуации,
или он является указателем на такой класс, а тип ожидаемой ситуации
тоже указатель ($$R.4.6).
Поскольку транслятору известна иерархия классов, он способен
обнаружить такие нелепые ошибки, когда обработчик catch (...) указан
не последним, или когда обработчик ситуации базового класса
предшествует обработчику производной от этого класса ситуации
($$R15.4). В обоих случая, последующий обработчик (или обработчики)
не могут быть запущены, поскольку они "маскируются" первым
обработчиком.
Если в некоторой функции потребуются определенные ресурсы, например,
нужно открыть файл, отвести блок памяти в области свободной
памяти, установить монопольные права доступа и т.д., для дальнейшей
работы системы обычно бывает крайне важно, чтобы ресурсы были
освобождены надлежащим образом. Обычно такой "надлежащий способ"
реализует функция, в которой происходит запрос ресурсов и освобождение
их перед выходом. Например:
void use_file(const char* fn)
{
FILE* f = fopen(fn,"w");
// работаем с f
fclose(f);
}
Все это выглядит вполне нормально до тех пор, пока вы не поймете,
что при любой ошибке, происшедшей после вызова fopen() и до вызова
fclose(), возникнет особая ситуация, в результате которой мы
выйдем из use_file(), не обращаясь к fclose().Ь
Ь Стоит сказать, что та же проблема возникает и в языках, не
поддерживающих особые ситуации. Так, обращение к функции longjump()
из стандартной библиотеки С может иметь такие же неприятные
последствия.
Если вы создаете устойчивую к ошибкам системам, эту проблему
придется решать. Можно дать примитивное решение:
void use_file(const char* fn)
{
FILE* f = fopen(fn,"w");
try {
// работаем с f
}
catch (...) {
fclose(f);
throw;
}
fclose(f);
}
Вся часть функции, работающая с файлом f, помещена в проверяемый
блок, в котором перехватываются все особые ситуации, закрывается
файл и особая ситуация запускается повторно.
Недостаток этого решения в его многословности, громоздкости
и потенциальной расточительности. К тому же всякое многословное
и громоздкое решение чревато ошибками, хотя бы в силу усталости
программиста. К счастью, есть более приемлемое решение. В общем
виде проблему можно сформулировать так:
void acquire()
{
// запрос ресурса 1
// ...
// запрос ресурса n
// использование ресурсов
// освобождение ресурса n
// ...
// освобождение ресурса 1
}
Как правило бывает важно, чтобы ресурсы освобождались в обратном
по сравнению с запросами порядке. Это очень сильно напоминает порядок
работы с локальными объектами, создаваемыми конструкторами и
уничтожаемыми деструкторами. Поэтому мы можем решить проблему запроса и
освобождения ресурсов, если будем использовать подходящие объекты
классов с конструкторами и деструкторами. Например, можно определить
класс FilePtr, который выступает как тип FILE* :
class FilePtr {
FILE* p;
public:
FilePtr(const char* n, const char* a)
{ p = fopen(n,a); }
FilePtr(FILE* pp) { p = pp; }
~FilePtr() { fclose(p); }
operator FILE*() { return p; }
};
Построить объект FilePtr можно либо, имея объект типа FILE*, либо,
получив нужные для fopen() параметры. В любом случае этот
объект будет уничтожен при выходе из его области видимости, и
его деструктор закроет файл. Теперь наш пример сжимается до такой
функции:
void use_file(const char* fn)
{
FilePtr f(fn,"w");
// работаем с f
}
Деструктор будет вызываться независимо от того, закончилась ли функция
нормально, или произошел запуск особой ситуации.
Описанный способ управления ресурсами обычно называют "запрос ресурсов
путем инициализации". Это универсальный прием, рассчитанный на
свойства конструкторов и деструкторов и их взаимодействие с
механизмом особых ситуаций.
Объект не считается построенным, пока не завершил выполнение его
конструктор. Только после этого возможна раскрутка стека,
сопровождающая вызов деструктора объекта. Объект, состоящий из
вложенных объектов, построен в той степени, в какой построены
вложенные объекты.
Хорошо написанный конструктор должен гарантировать, что объект
построен полностью и правильно. Если ему не удается сделать это,
он должен, насколько это возможно, восстановить состояние системы,
которое было до начала построения. Для простых конструкторов было бы
идеально всегда удовлетворять хотя бы одному условию - правильности
или законченности объектов, и никогда не оставлять объект
в "наполовину построенном" состоянии. Этого можно добиться, если
применять при построении членов способ "запроса ресурсов путем
инициализации".
Рассмотрим класс X, конструктору которого требуется два ресурса:
файл x и замок y (т.е. монопольные права доступа к чему-либо).
Эти запросы могут быть отклонены и привести к запуску особой
ситуации. Чтобы не усложнять работу программиста, можно потребовать,
чтобы конструктор класса X никогда не завершался тем, что запрос на
файл удовлетворен, а на замок нет. Для представления двух видов
ресурсов мы будем использовать объекты двух классов FilePtr и
LockPtr (естественно, было бы достаточно одного класса, если x и y
ресурсы одного вида). Запрос ресурса выглядит как инициализация
представляющего ресурс объекта:
class X {
FilePtr aa;
LockPtr bb;
// ...
X(const char* x, const char* y)
: aa(x), // запрос `x'
bb(y) // запрос `y'
{ }
// ...
};
Теперь, как это было для случая локальных объектов, всю служебную
работу, связанную с ресурсами, можно возложить на реализацию.
Пользователь не обязан следить за ходом такой работой. Например,
если после построения aa и до построения bb возникнет особая
ситуация, то будет вызван только деструктор aa, но не bb.
Это означает, что если строго придерживаться этой простой
схемы запроса ресурсов, то все будет в порядке. Еще более важно
то, что создателю конструктора не нужно самому писать обработчики
особых ситуаций.
Для требований выделить блок в свободной памяти характерен самый
произвольный порядок запроса ресурсов. Примеры таких запросов уже
неоднократно встречались в этой книге:
class X {
int* p;
// ...
public:
X(int s) { p = new int[s]; init(); }
~X() { delete[] p; }
// ...
};
Это типичный пример использования свободной памяти, но в совокупности с
особыми ситуациями он может привести к ее исчерпанию памяти.
Действительно, если в init() запущена особая ситуация, то отведенная
память не будет освобождена. Деструктор не будет вызываться, поскольку
построение объекта не было завершено. Есть более надежный вариант
этого примера:
template<class T> class MemPtr {
public:
T* p;
MemPtr(size_t s) { p = new T[s]; }
~MemPtr() { delete[] p; }
operator T*() { return p; }
}
class X {
MemPtr<int> cp;
// ...
public:
X(int s):cp(s) { init(); }
// ...
};
Теперь уничтожение массива, на который указывает p, происходит неявно
в MemPtr. Если init() запустит особую ситуацию, отведенная память
будет освобождена при неявном вызове деструктора для полностью
построенного вложенного объекта cp.
Отметим также, что стандартная стратегия выделения памяти в С++
гарантирует, что если функции operator new() не удалось выделить память
для объекта, то конструктор для него никогда не будет вызываться. Это
означает, что пользователю не надо опасаться, что конструктор или
деструктор может быть вызван для несуществующего объекта.
Теоретически дополнительные расходы, требующиеся для обработки
особых ситуаций, когда на самом деле ни одна из них не возникла, могут
быть сведены к нулю. Однако, вряд ли это верно для ранних
реализациях языка. Поэтому будет разумно в критичных внутренних циклах
программы пока не использовать локальные переменные классов
с деструкторами.
Не все программы должны быть устойчивы ко всем видам ошибок. Не все
ресурсы являются настолько критичными, чтобы оправдать попытки
защитить их с помощью описанного способа "запроса ресурсов путем
инициализации". Есть множество программ, которые просто читают
входные данные и выполняются до конца. Для них самой подходящей
реакцией на динамическую ошибку будет просто прекращение счета
(после выдачи соответствующего сообщения). Освобождение всех
затребованных ресурсов возлагается на систему, а пользователь
должен произвести повторный запуск программы с более подходящими
входными данными. Наша схема предназначена для задач, в которых
такая примитивная реакция на динамическую ошибку неприемлема.
Например, разработчик библиотеки обычно не в праве делать допущения
о том, насколько устойчива к ошибкам, должна быть программа,
работающая с библиотекой. Поэтому он должен учитывать все динамические
ошибки и освобождать все ресурсы до возврата из библиотечной функции
в пользовательскую программу. Метод "запроса ресурсов путем
инициализации" в совокупности с особыми ситуациями, сигнализирующими
об ошибке, может пригодиться при создании многих библиотек.
Есть одна из вечных проблем программирования: что делать, если не
удалось удовлетворить запрос на ресурс? Например, в предыдущем
примере мы спокойно открывали с помощью fopen() файлы и запрашивали с
помощью операции new блок свободной памяти, не задумываясь при этом,
что такого файла может не быть, а свободная память может исчерпаться.
Для решения такого рода проблем у программистов есть два способа:
Повторный запрос: пользователь должен изменить свой запрос и
повторить его.
Завершение: запросить дополнительные ресурсы от системы, если
их нет, запустить особую ситуацию.
Первый способ предполагает для задания приемлемого запроса
содействие пользователя, во втором пользователь должен быть готов
правильно отреагировать на отказ в выделении ресурсов. В большинстве
случаев последний способ намного проще и позволяет поддерживать в
системе разделение различных уровней абстракции.
В С++ первый способ поддержан механизмом вызова функций, а
второй - механизмом особых ситуаций. Оба способа можно
продемонстрировать на примере реализации и использования операции
new:
#include <stdlib.h>
extern void* _last_allocation;
extern void* operator new(size_t size)
{
void* p;
while ( (p=malloc(size))==0 ) {
if (_new_handler)
(*_new_handler)(); // обратимся за помощью
else
return 0;
}
return _last_allocation=p;
}
Если операция new() не может найти свободной памяти, она обращается
к управляющей функции _new_handler(). Если в _new_handler() можно
выделить достаточный объем памяти, все нормально. Если нет, из
управляющей функции нельзя возвратиться в операцию new, т.к.
возникнет бесконечный цикл. Поэтому управляющая функция может
запустить особую ситуацию и предоставить исправлять положение
программе, обратившейся к new:
void my_new_handler()
{
try_find_some_memory(); // попытаемся найти
// свободную память
if (found_some()) return; // если она найдена, все в порядке
throw Memory_exhausted(); // иначе запускаем особую
// ситуацию "Исчерпание_памяти"
}
Где-то в программе должен быть проверяемый блок с соответствующим
обработчиком:
try {
// ...
}
catch (Memory_exhausted) {
// ...
}
В функции operator new() использовался указатель на управляющую
функцию _new_handler, который настраивается стандартной функцией
set_new_handler(). Если нужно настроиться на собственную управляющую
функцию, надо обратиться так
set_new_handler(&my_new_handler);
Перехватить ситуацию Memory_exhausted можно следующим образом:
void (*oldnh)() = set_new_handler(&my_new_handler);
try {
// ...
}
catch (Memory_exhausted) {
// ...
}
catch (...) {
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
throw(); // повторный запуск особой ситуации
}
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
Можно поступить еще лучше, если к управляющей функции применить
описанный в $$9.4 метод "запроса ресурсов путем инициализации" и
убрать обработчик catch (...).
В решении, использующим my_new_handler(), от точки обнаружения
ошибки до функции, в которой она обрабатывается, не передается
никакой информации. Если нужно передать какие-то данные, то
пользователь может включить свою управляющую функцию в класс.
Тогда в функции, обнаружившей ошибку, нужные данные можно поместить в
объект этого класса. Подобный способ, использующий объекты-функции,
применялся в $$10.4.2 для реализации манипуляторов. Способ, в
котором используется указатель на функцию или объект-функция для
того, чтобы из управляющей функции, обслуживающей некоторый ресурс,
произвести "обратный вызов" функции запросившей этот ресурс,
обычно называется просто обратным вызовом (callback).
При этом нужно понимать, что чем больше информации передается
из обнаружившей ошибку функции в функцию, пытающуюся ее исправить,
тем больше зависимость между этими двумя функциями. В общем случае
лучше сводить к минимуму такие зависимости, поскольку всякое
изменение в одной из функций придется делать с учетом другой функцией,
а, возможно, ее тоже придется изменять. Вообще, лучше не смешивать
отдельные компоненты программы. Механизм особых ситуаций позволяет
сохранять раздельность компонентов лучше, чем обычный механизм вызова
управляющих функций, которые задает функция, затребовавшая ресурс.
В общем случае разумный подход состоит в том, чтобы выделение
ресурсов было многоуровневым (в соответствии с уровнями абстракции).
При этом нужно избегать того, чтобы функции одного уровня зависели
от управляющей функции, вызываемой на другом уровне. Опыт создания
больших программных систем показывает, что со временем удачные
системы развиваются именно в этом направлении.
Особые ситуации дают средство сигнализировать о происходящих в
конструкторе ошибках. Поскольку конструктор не возвращает такое
значение, которое могла бы проверить вызывающая функция, есть
следующие обычные (т.е. не использующие особые ситуации) способы
сигнализации:
[1] Возвратить объект в ненормальном состоянии в расчете,
что пользователь проверит его состояние.
[2] Установить значение нелокальной переменной, которое
сигнализирует, что создать объект не удалось.
Особые ситуации позволяют тот факт, что создать объект не удалось,
передать из конструктора вовне:
Vector::Vector(int size)
{
if (sz<0 || max<sz) throw Size();
// ...
}
В функции, создающей вектора, можно перехватить ошибки, вызванные
недопустимым размером (Size()) и попытаться на них отреагировать:
Vector* f(int i)
{
Vector* p;
try {
p = new Vector v(i);
}
catch (Vector::Size) {
// реакция на недопустимый размер вектора
}
// ...
return p;
}
Управляющая созданием вектора функция способна правильно
отреагировать на ошибку. В самом обработчике особой ситуации можно
применить какой-нибудь из стандартных способов диагностики и
восстановления после ошибки. При каждом перехвате особой ситуации
в управляющей функции может быть свой взгляд на причину ошибки. Если
с каждой особой ситуацией передаются описывающие ее данные, то объем
данных, которые нужно анализировать для каждой ошибки, растет. Основная
задача обработки ошибок в том, чтобы обеспечить надежный и удобный
способ передачи данных от исходной точки обнаружения ошибки до того
места, где после нее возможно осмысленное восстановление.
Способ "запроса ресурсов путем инициализации" - самый надежное
и красивое решение в том случае, когда имеются конструкторы, требующие
более одного ресурса. По сути он позволяет свести задачу выделения
нескольких ресурсов к повторно применяемому, более простому, способу,
рассчитанному на один ресурс.
Если особая ситуация ожидалась, была перехвачена и не оказала
плохого воздействия на ход программы, то стоит ли ее называть
ошибкой? Так говорят только потому, что программист думает о ней
как об ошибке, а механизм особых ситуаций является средством
обработки ошибок. С другой стороны, особые ситуации можно
рассматривать просто как еще одну структуру управления. Подтвердим
это примером:
class message { /* ... */ }; // сообщение
class queue { // очередь
// ...
message* get(); // вернуть 0, если очередь пуста
// ...
};
void f1(queue& q)
{
message* m = q.get();
if (m == 0) { // очередь пуста
// ...
}
// используем m
}
Этот пример можно записать так:
class Empty { } // тип особой ситуации "Пустая_очередь"
class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
// ...
};
void f2(queue& q)
{
try {
message* m = q.get();
// используем m
}
catch (Empty) { // очередь пуста
// ...
}
}
В варианте с особой ситуацией есть даже какая-то прелесть. Это
хороший пример того, когда трудно сказать, можно ли считать
такую ситуацию ошибкой. Если очередь не должна быть пустой
(т.е. она бывает пустой очень редко, скажем один раз из тысячи),
и действия в случае пустой очереди можно рассматривать как
восстановление, то в функции f2() взгляд на особую ситуацию будет
такой, которого мы до сих пор и придерживались (т.е. обработка особых
ситуаций есть обработка ошибок). Если очередь часто бывает пустой,
а принимаемые в этом случае действия образуют одну из ветвей
нормального хода программы, то придется отказаться от такого взгляда
на особую ситуацию, а функцию f2() надо переписать:
class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
int empty();
// ...
};
void f3(queue& q)
{
if (q.empty()) { // очередь пуста
// ...
}
else {
message* m = q.get();
// используем m
}
}
Отметим, что вынести из функции get() проверку очереди на пустоту
можно только при условии, что к очереди нет параллельных обращений.
Не так то просто отказаться от взгляда, что обработка особой
ситуации есть обработка ошибки. Пока мы придерживаемся такой точки
зрения, программа четко подразделяется на две части: обычная часть
и часть обработки ошибок. Такая программа более понятна. К сожалению,
в реальных задачах провести четкое разделение невозможно, поэтому
структура программы должна (и будет) отражать этот факт. Допустим,
очередь бывает пустой только один раз (так может быть, если функция
get() используется в цикле, и пустота очереди говорит о конце цикла).
Тогда пустота очереди не является чем-то странным или ошибочным.
Поэтому, используя для обозначения конца очереди особую ситуацию,
мы расширяем представление об особых ситуациях как ошибках. С другой
стороны, действия, принимаемые в случае пустой очереди, явно отличаются
от действий, принимаемых в ходе цикла (т.е. в обычном случае).
Механизм особых ситуаций является менее структурированным,
чем такие локальные структуры управления как операторы if или for.
Обычно он к тому же является не столь эффективным, если особая
ситуация действительно возникла. Поэтому особые ситуации следует
использовать только в том случае, когда нет хорошего решения с более
традиционными управляющими структурами, или оно, вообще, невозможно.
Например, в случае пустой очереди можно прекрасно использовать для
сигнализации об этом значение, а именно нулевое значение указателя на
строку message, значит особая ситуация здесь не нужна. Однако, если бы
из класса queue мы получали вместо указателя значение типа int, то
то могло не найтись такого значения, обозначающего пустую очередь.
В таком случае функция get() становится эквивалентной операции
индексации из $$9.1, и более привлекательно представлять пустую очередь