Для упрощения сопровождения я всегда использую error в качестве своего базового класса для исключений. (Я не мог использовать производный класс, даже если здесь был бы возможен всего один вид ошибки). Таким образом, я знаю, что, имея возбуждающий исключение класс some class, можно перехватить это исключение при помощи:

catch(some class::error &r)

Эту ошибку искать не придется. Если применяется наследование, то я использую базовый класс error таким образом:

class employee

public:

class error {};

class database access error : public error {};

class peon : public employee

class error : public employee::error {}; class aagh : public error {};

Этим способом исключение aagh может быть перехвачено как peon::aagh, peon::error или employee::error.

Нет смысла создавать класс глобального уровня error, от которого наследуются все локальные классы error, потому что для обработки этой ситуации вы можете использовать обработчик catch ( ).

161. Возбуждение исключений из конструктора ненадежно

Я начну этот раздел с замечания о том, что компиляторы, которые соответствуют рабочим документам комитета ISO/ANSI по Си++, не имеют большей части из рассматриваемых здесь проблем. Тем не менее, многие компиляторы (один из которых компилятор Microsoft) им не соответствуют.

Ошибки в конструкторах являются действительной проблемой Си++. Так как они не вызываются явно, то и не могут возвратить коды ошибок обычным путем. Задание для конструируемого объекта неверного значения в лучшем случае громоздко и иногда невозможно. Возбуждение исключения может быть здесь решением, но при этом нужно учесть множество вопросов. Рассмотрим следующий код:

class c

class error {}; int *pi; public:

c() { throw error(); }

...

void f( void )

c *cp = new c; cp не инициализируется, если не выполняется конструктор

...

delete cp; эта строка в любом случае не выполнится.

catch( c::error &err ) {

printf ( Сбой конструктора\n );

delete cp; Дефект: cp теперь содержит мусор

Проблема состоит в том, что память, выделенная оператором new, никогда не освобождается. То есть, компилятор сначала выделяет память, затем вызывает конструктор, который возбуждает объект error. Затем управление передается прямо из конструктора в catch-блок. Код, которым возвращаемое значение оператора new присваивается cp, никогда не выполняется - управление просто перескакивает через него. Следовательно, отсутствует возможность освобождения памяти, потому что у вас нет соответствующего указателя. Чтение мной рабочих документов комитета ISO/ANSI по Си++ показало, что такое поведение некорректно - память должна освобождаться неявно. Тем не менее, многие компиляторы делают это неправильно.

Вот простой способ исправить эту сложную ситуацию (я поместил тело функции в определение класса лишь для того, чтобы сделать пример покороче):

class с

int *pi; public:

c() { /*...*/ throw this; }

void f( void )

c *cp = NULL; cp = new c;

c a c object();

catch( c *points at unconstructed object ) {

if( !cp ) если конструктор, вызванный посредством new, не выполняется delete points at unconstructed object;

Ситуация усложняется, когда некоторые объекты размещаются при помощи new, а другие - из динамической памяти. Вы должны сделать что-то похожее на следующее, чтобы понять, в чем дело: void f( void )

c *cp = NULL; cp должен быть объявлен снаружи try-блока, потому что try-блок образует область действия, поэтому cp не может быть доступн1м в catch-блоке будучи объявлен в try-блоке.

c a c object; cp = new c;

catch( c *points at unconstructed object ) {

if( !cp ) если конструктор, вызванный посредством new, не выполняется delete points at unconstructed object;

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

Во всех предыдущих примерах деструктор для сбойных объектов вызывается, даже если конструктор не выполнился и возбудил исключение. (Он вызывается или косвенно посредством оператора delete, или неявно при выходе объекта из области действия, даже если он покидает ее из-за возбуждения исключения).

Аналогично, вызов delete косвенно вызывает деструктор для этого объекта. Я сейчас вернусь к этой ситуации. Перед выходом из этого