* законченный учебник и руководство по языку

Вид материала

Подобный материал:

1 ... 14 15 16 17 18 19 20 21 ... 34

& ai, Allocator& ad)

{

try {

// ...

}

catch (Allocator::Exhausted) {

// ...

}

catch (Allocator::Exhausted) {

// ...

}

}

С другой стороны, особая ситуация может быть общей для всех

созданных по шаблону классов:

class Allocator_Exhausted { };

template class Allocator {

// ...

T* get();

};

void f(Allocator& ai, Allocator& ad)

{

try {

// ...

}

catch (Allocator_Exhausted) {

// ...

}

}

Какой способ задания особой ситуации предпочтительней, сказать трудно.

Выбор зависит от назначения рассматриваемого шаблона.

9.3.1 Группирование особых ситуаций

Особые ситуации естественным образом разбиваются на семейства.

Действительно, логично представлять семейство Matherr, в которое

входят Overflow (переполнение), Underflow (потеря значимости) и

некоторые другие особые ситуации. Семейство Matherr образуют

особые ситуации, которые могут запускать математические функции

стандартной библиотеки.

Один из способов задания такого семейства сводится к определению

Matherr как типа, возможные значения которого включают Overflow и

все остальные:

enum { Overflow, Underflow, Zerodivide, /* ... */ };

try {

// ...

}

catch (Matherr m) {

switch (m) {

case Overflow:

// ...

case Underflow:

// ...

// ...

}

// ...

}

Другой способ предполагает использование наследования и виртуальных

функций, чтобы не вводить переключателя по значению поля типа.

Наследование помогает описать семейства особых ситуаций:

class Matherr { };

class Overflow: public Matherr { };

class Underflow: public Matherr { };

class Zerodivide: public Matherr { };

// ...

Часто бывает так, что нужно обработать особую ситуацию Matherr

не зависимо от того, какая именно ситуация из этого семейства

произошла. Наследование позволяет сделать это просто:

try {

// ...

}

catch (Overflow) {

// обработка Overflow или любой производной ситуации

}

catch (Matherr) {

// обработка любой отличной от Overflow ситуации

}

В этом примере Overflow разбирается отдельно, а все другие особые

ситуации из Matherr разбираются как один общий случай. Конечно,

функция, содержащая catch (Matherr), не будет знать какую именно

особую ситуацию она перехватывает. Но какой бы она ни была, при

входе в обработчик передаваемая ее копия будет Matherr. Обычно это

как раз то, что нужно. Если это не так, особую ситуацию можно

перехватить по ссылке (см. $$9.3.2).

Иерархическое упорядочивание особых ситуаций может играть важную

роль для создания ясной структуры программы. Действительно, пусть

такое упорядочивание отсутствует, и нужно обработать все особые

ситуации стандартной библиотеки математических функций. Для этого

придется до бесконечности перечислять все возможные особые ситуации:

try {

// ...

}

catch (Overflow) { /* ... */ }

catch (Underflow) { /* ... */ }

catch (Zerodivide) { /* ... */ }

// ...

Это не только утомительно, но и опасно, поскольку можно забыть

какую-нибудь особую ситуацию. Кроме того, необходимость перечислить

в проверяемом блоке все особые ситуации практически гарантирует,

что, когда семейство особых ситуаций библиотеки расширится, в

программе пользователя возникнет ошибка. Это значит, что при

введении новой особой ситуации в библиотеки математических функций

придется перетранслировать все части программы, которые содержат

обработчики всех особых ситуаций из Matherr. В общем случае такая

перетрансляция неприемлема. Часто даже нет возможности найти

все требующие перетрансляции части программы. Если такая

возможность есть, нельзя требовать, чтобы всегда был

доступен исходной текст любой части большой программы, или чтобы у нас

были права изменять любую часть большой программы, исходный текст

которой мы имеем. На самом деле, пользователь не должен думать

о внутреннем устройстве библиотек. Все эти проблемы перетрансляции

и сопровождения могут привести к тому, что после создания

первой версии библиотеки будет нельзя вводить в ней новые

особые ситуации. Но такое решение не подходит практически для всех

библиотек.

Все эти доводы говорят за то, что особые ситуации нужно

определять как иерархию классов (см. также $$9.6.1). Это, в свою

очередь, означает, что особые ситуации могут быть членами нескольких

групп:

class network_file_err // ошибки файловой системы в сети

: public network_err, // ошибки сети

public file_system_err { // ошибки файловой системы

// ...

};

Особую ситуацию network_file_err можно перехватить в функциях,

обрабатывающих особые ситуации сети:

void f()

{

try {

// какие-то операторы

}

catch (network_err) {

// ...

}

}

Ее также можно перехватить в функциях, обрабатывающих особые ситуации

файловой системы:

void g()

{

try {

// какие-то другие операторы

}

catch (file_system_err) {

// ...

}

}

Это важный момент, поскольку такой системный сервис как работа в

сети должен быть прозрачен, а это означает, что создатель функции

g() может даже и не знать, что эта функция будет выполняться

в сетевом режиме.

Отметим, что в настоящее время нет стандартного множества

особых ситуаций для стандартной математической библиотеки и

библиотеки ввода-вывода. Задача комитетов ANSI и ISO по стандартизации

С++ решить нужно ли такое множество и какие в нем следует использовать

имена и классы.

Поскольку можно сразу перехватить все особые ситуации

(см. $$9.3.2), нет настоятельной необходимости создавать для этой

цели общий, базовый для всех особых ситуаций, класс. Однако, если

все особые ситуации являются производными от пустого класса

Exception (особая ситуация), то в интерфейсах их использование

становится более регулярным (см. $$9.6). Если вы используете общий

базовый класс Exception, убедитесь, что в нем ничего нет кроме

виртуального деструктора. В противном случае такой класс может

вступить в противоречие с предполагаемым стандартом.

9.3.2 Производные особые ситуации

Если для обработки особых ситуаций мы используем иерархию классов,

то, естественно, каждый обработчик должен разбираться только с

частью информации, передаваемой при особых ситуациях. Можно сказать,

что, как правило, особая ситуация перехватывается обработчиком

ее базового класса, а не обработчиком класса, соответствующего

именно этой особой ситуации. Именование и перехват обработчиком особой

ситуации семантически эквивалентно именованию и получению параметра

в функции. Проще говоря, формальный параметр инициализируется

значением фактического параметра. Это означает, что запущенная

особая ситуация "низводится" до особой ситуации, ожидаемой

обработчиком. Например:

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). В обоих случая, последующий обработчик (или обработчики)

не могут быть запущены, поскольку они "маскируются" первым

обработчиком.

9.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

}

Деструктор будет вызываться независимо от того, закончилась ли функция

нормально, или произошел запуск особой ситуации.

9.4.1 Конструкторы и деструкторы

Описанный способ управления ресурсами обычно называют "запрос ресурсов

путем инициализации". Это универсальный прием, рассчитанный на

свойства конструкторов и деструкторов и их взаимодействие с

механизмом особых ситуаций.

Объект не считается построенным, пока не завершил выполнение его

конструктор. Только после этого возможна раскрутка стека,

сопровождающая вызов деструктора объекта. Объект, состоящий из

вложенных объектов, построен в той степени, в какой построены

вложенные объекты.

Хорошо написанный конструктор должен гарантировать, что объект

построен полностью и правильно. Если ему не удается сделать это,

он должен, насколько это возможно, восстановить состояние системы,

которое было до начала построения. Для простых конструкторов было бы

идеально всегда удовлетворять хотя бы одному условию - правильности

или законченности объектов, и никогда не оставлять объект

в "наполовину построенном" состоянии. Этого можно добиться, если

применять при построении членов способ "запроса ресурсов путем

инициализации".

Рассмотрим класс 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 MemPtr {

public:

T* p;

MemPtr(size_t s) { p = new T[s]; }

~MemPtr() { delete[] p; }

operator T*() { return p; }

}

class X {

MemPtr

Blog

* законченный учебник и руководство по языку