9.1.2 Другие точки зрения на особые ситуации

"Особая ситуация" - одно из тех понятий, которые имеют разный смысл

для разных людей. В С++ механизм особых ситуаций предназначен для

обработки ошибок. В частности, он предназначен для обработки ошибок

в программах, состоящих из независимо создаваемых компонентов.

Этот механизм рассчитан на особые ситуации, возникающие только при

последовательном выполнении программы (например, контроль границ

массива). Асинхронные особые ситуации такие, например, как прерывания

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

механизма. В различных системах существуют другие механизмы,

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

от конкретной системы.

Механизм особых ситуаций является конструкцией с нелокальной

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

return. Поэтому особые ситуации можно использовать для целей, никак

не связанных с обработкой ошибок ($$9.5). Все-таки основным

назначением механизма особых ситуаций и темой этой главы будет

обработка ошибок и создание устойчивых к ошибкам программ.

9.2 Различение особых ситуаций

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

ошибок. Эти ошибки можно сопоставить с особыми ситуациями, имеющими

различные имена. Так, в классе Vector обычно приходится выявлять

и сообщать об ошибках двух видов: ошибки диапазона и ошибки,

вызванные неподходящим для конструктора параметром:

class Vector {

int* p;

int sz;

public:

enum { max = 32000 };

class Range { }; // особая ситуация индекса

class Size { }; // особая ситуация "неверный размер"

Vector(int sz);

int& operator[](int i);

// ...

};

Как было сказано, операция индексации запускает особую ситуацию

Range, если ей задан выходящий из диапазона значений индекс.

Конструктор запускает особую ситуацию Size, если ему задан

недопустимый размер вектора:

Vector::Vector(int sz)

{

if (sz<0 || max<sz) throw Size();

// ...

}

Пользователь класса Vector может различить эти две особые ситуации,

если в проверяемом блоке (т.е. в блоке оператора try) укажет

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

void f()

{

try {

use_vectors();

}

catch (Vector::Range) {

// ...

}

catch (Vector::Size) {

// ...

}

}

В зависимости от особой ситуации будет выполняться соответствующий

обработчик. Если управление дойдет до конца операторов обработчика,

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

обработчиков:

void f()

{

try {

use_vectors();

}

catch (Vector::Range) {

// исправить индекс и

// попробовать опять:

f();

}

catch (Vector::Size) {

cerr << "Ошибка в конструкторе Vector::Size";

exit(99);

}

// сюда мы попадем, если вообще не было особых ситуаций

// или после обработки особой ситуации Range

}

Список обработчиков напоминает переключатель, но здесь в теле

обработчика операторы break не нужны. Синтаксис списка обработчиков

отличен от синтаксиса вариантов case переключателя частично по

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

обработчик определяет свою область видимости (см. $$9.8).

Не обязательно все особые ситуации перехватывать в одной функции:

void f1()

{

try {

f2(v);

}

catch (Vector::Size) {

// ...

}

}

void f2(Vector& v)

{

try {

use_vectors();

}

catch (Vector::Range) {

// ...

}

}

Здесь f2() перехватит особую ситуацию Range, возникающую в

use_vectors(), а особая ситуация Size будет оставлена для f1().

С точки зрения языка особая ситуация считается обработанной сразу

при входе в тело ее обработчика. Поэтому все особые ситуации,

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

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

Значит в следующем примере не возникнет бесконечного цикла:

try {

// ...

}

catch (input_overflow) {

// ...

throw input_overflow();

}

Здесь input_overflow (переполнение при вводе) - имя глобального класса.

Обработчики особых ситуаций могут быть вложенными:

try {

// ...

}

catch (xxii) {

try {

// сложная реакция

}

catch (xxii) {

// ошибка в процессе сложной реакции

}

}

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

и чаще всего она является свидетельством плохого стиля.

9.3 Имена особых ситуаций

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

запускается ведь не тип, а объект. Если нам нужно передать некоторую

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

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

значение индекса, выходящее за границы диапазона:

class Vector {

// ...

public:

class Range {

public:

int index;

Range(int i) : index(i) { }

};

// ...

int& operator[](int i)

// ...

};

int Vector::operator[](int i)

{

if (o<=i && i <sz) return p[i];

throw Range(i);

}

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

нужно дать имя объекту, представляющему особую ситуацию:

void f(Vector& v)

{

// ...

try {

do_something(v);

}

catch (Vector::Range r ) {

cerr << "недопустимый индекс" << r.index << '\n';

// ...

}

// ...

}

Конструкция в скобках после служебного слова catch является по сути

описанием и она аналогична описанию формального параметра функции.

В ней указывается каким может быть тип параметра (т.е. особой

ситуации) и может задаваться имя для фактической, т.е. запущенной,

особой ситуации. Вспомним, что в шаблонах типов у нас был выбор

для именования особых ситуаций. В каждом созданном по шаблону классе

был свой класс особой ситуации:

template<class T> class Allocator {

// ...

class Exhausted { }

// ...

T* get();

};

void f(Allocator<int>& ai, Allocator<double>& ad)

{

try {

// ...

}

catch (Allocator<int>::Exhausted) {

// ...

}

catch (Allocator<double>::Exhausted) {

// ...

}

}

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

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

class Allocator_Exhausted { };

template<class T> class Allocator {

// ...

T* get();

};

void f(Allocator<int>& ai, Allocator<double>& 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, убедитесь, что в нем ничего нет кроме

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

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