<< Пред. стр. 95 (из 121) След. >>
Список литературы по разделу
}
catch ( Excp ) {
// обрабатывает другие исключения
}
catch-обработчик для производного класса должен идти первым. Тогда catch-обработчик для базового класса получит управление только в том случае, если более специализированного обработчика не нашлось.
Если исключения организованы в иерархии, то пользователи библиотеки классов могут выбрать в своем приложении уровень детализации при работе с исключениями, возбужденными внутри библиотеки. Например, кодируя функцию main(), мы решили, что исключения типа pushOnFull должны обрабатываться несколько иначе, чем прочие, и потому написали для них специализированный catch-обработчик. Что касается остальных исключений, то они обрабатываются единообразно:
catch ( pushOnFull eObj ) {
// используется функция-член value() класса pushOnFull
// см. раздел 11.3
cerr << "попытка поместить значение " << eObj.value()
<< " в полный стек\n";
}
catch ( Excp ) {
// используется функция-член print() базового класса
Excp::print( "произошло исключение" );
}
Как отмечалось в разделе 11.3, процесс поиска catch-обработчика для возбужденного исключения не похож на процесс разрешения перегрузки функций. При выборе наилучшей из устоявших функций принимаются во внимание все кандидаты, видимые в точке вызова, а при обработке исключений найденный catch-обработчик совсем не обязательно будет лучше остальных соответствовать типу исключения. Выбирается первый подходящий обработчик, т.е. первый из просмотренных, который способен обработать данное исключение. Поэтому в списке обработчиков наиболее специализированные должны стоять ближе к началу.
Объявление исключения в catch-обработчике (находящееся в скобках после слова catch) очень похоже на объявление параметра функции. В приведенном примере оно напоминает параметр, передаваемый по значению. Объект eObj инициализируется копией значения объекта-исключения точно так же, как передаваемый по значению формальный параметр функции инициализируется значением фактического аргумента. Как и в случае с параметрами функции, в объявлении исключения можно использовать ссылки. Тогда catch-обработчик имеет доступ непосредственно к объекту-исключению, созданному выражением throw, а не к его локальной копии. Чтобы избежать копирования больших объектов, параметры типа класса следует объявлять как ссылки; в объявлениях исключений тоже желательно делать исключения типа класса ссылками. В зависимости от того, что находится в таком объявлении (объект или ссылка), поведение обработчика различается (мы покажем эти различия в данном разделе).
В главе 11 были введены выражения повторного возбуждения исключения, которые используются в catch-обработчике для передачи исключения какому-то другому обработчику выше в цепочке вызовов. Такое выражение имеет вид
throw;
Как ведет себя эта инструкция, если она расположена в catch-обработчике исключений базового класса? Например, каким будет тип повторно возбужденного исключения, если mathFunc() возбуждает исключение типа divideByZero?
void calculate( int parm ) {
try {
mathFunc( parm ); // возбуждает исключение divideByZero
}
catch ( mathExcp mExcp ) {
// частично обрабатывает исключение
// и генерирует объект-исключение еще раз
throw;
}
}
Будет ли повторно возбужденное исключение иметь тип divideByZero –тот же, что и исключение, возбужденное функцией mathFunc()? Или тип mathExcp, который указан в объявлении исключения в catch-обработчике?
Напомним, что выражение throw повторно генерирует исходный объект-исключение. Так как исходный объект имеет тип divideByZero, то повторно возбужденное исключение будет такого же типа. В catch-обработчике объект mExcp инициализируется копией подобъекта объекта типа divideByZero, который соответствует его базовому классу MathExcp. Доступ к ней осуществляется только внутри catch-обработчика, она не является исходным объектом-исключением, который повторно генерируется.
Предположим, что классы в нашей иерархии исключений имеют деструкторы:
class pushOnFull {
public:
pushOnFull( int i ) : _value( i ) { }
int value() { return _value; }
~pushOnFull(); // вновь объявленный деструктор
private:
int _value;
};
Когда они вызываются? Чтобы ответить на этот вопрос, рассмотрим catch-обработчик:
catch ( pushOnFull eObj ) {
cerr << "попытка поместить значение " << eObj.value()
<< " в полный стек\n";
}
Поскольку в объявлении исключения eObj объявлен как локальный для catch-обработчика объект, а в классе pushOnFull есть деструктор, то eObj уничтожается при выходе из обработчика. Когда же вызывается деструктор для объекта-исключения, созданного в момент возбуждения исключения, – при входе в catch-обработчик или при выходе из него? Однако уничтожать исключение в любой из этих точек может быть слишком рано. Можете сказать, почему? Если catch-обработчик возбуждает исключение повторно, передавая его выше по цепочке вызовов, то уничтожать объект-исключение нельзя до момента выхода из последнего catch-обработчика.
19.2.4. Объекты-исключения и виртуальные функции
Если сгенерированный объект-исключение имеет тип производного класса, а обрабатывается catch-обработчиком для базового, то этот обработчик не может использовать особенности производного класса. Например, к функции-члену value(), которая объявлена в классе pushOnFull, нельзя обращаться в catch-обработчике Excp:
catch ( const Excp &eObj ) {
// ошибка: в классе Excp нет функции-члена value()
cerr << "попытка поместить значение " << eObj.value()
<< " в полный стек\n";
}
Но мы можем перепроектировать иерархию классов исключений и определить виртуальные функции, которые можно вызывать из catch-обработчика для базового класса Excp с целью получения доступа к функциям-членам более специализированного производного:
// новые определения классов, включающие виртуальные функции
class Excp {
public:
virtual void print( string msg ) {
cerr << "Произошло исключение"
<< endl;
}
};
class stackExcp : public Excp { };
class pushOnFull : public stackExcp {
public:
virtual void print() {
cerr << "попытка поместить значение " << _value
<< " в полный стек\n";
}
// ...
};
Функцию print() теперь можно использовать в catch-обработчике следующим образом:
int main() {
try {
// iStack::push() возбуждает исключение pushOnFull
} catch ( Excp eObj ) {
eObj.print(); // хотим вызвать виртуальную функцию,
// но вызывается экземпляр из базового класса
}
}
Хотя возбужденное исключение имеет тип pushOnFull, а функция print() виртуальна, инструкция eObj.print() печатает такую строку:
Произошло исключение
Вызываемая print() является членом базового класса Excp, а не замещает ее в производном. Но почему?
Вспомните, что объявление исключения в catch-обработчике ведет себя почти так же, так объявление параметра. Когда управление попадает в catch-обработчик, то, поскольку в нем объявлен объект, а не ссылка, eObj инициализируется копией подобъекта Excp базового класса объекта исключения. Поэтому eObj – это объект типа Excp, а не pushOnFull. Чтобы вызвать виртуальные функции из производных классов, в объявлении исключения должен быть указатель или ссылка:
int main() {
try {
// iStack::push() возбуждает исключение pushOnFull
} catch ( const Excp &eObj ) {
eObj.print(); // вызывается виртуальная функция
// pushOnFull::print()
}
}
Объявление исключения в этом примере тоже относится к базовому классу Excp, но так как eObj – ссылка и при этом именует объект-исключение типа pushOnFull, то для нее можно вызывать виртуальные функции, определенные в классе pushOnFull. Когда catch-обработчик обращается к виртуальной функции print(), вызывается функция из производного класса, и программа печатает следующую строку:
попытка поместить значение 879 в полный стек
Таким образом, ссылка в объявлении исключения позволяет вызывать виртуальные функции, ассоциированные с классом объекта-исключения.
19.2.5. Раскрутка стека и вызов деструкторов
Когда возбуждается исключение, поиск его catch-обработчика – раскрутка стека – начинается с функции, возбудившей исключение, и продолжается вверх по цепочке вложенных вызовов (см. раздел 11.3).
Во время раскрутки поочередно происходят аномальные выходы из просмотренных функций. Если функция захватила некоторый ресурс (например, открыла файл или выделила из хипа память), он в таком случае не освобождается.
Существует прием, позволяющий решить эту проблему. Всякий раз, когда во время поиска обработчика происходит выход из составной инструкции или блока, где определен некоторый локальный объект, для этого объекта автоматически вызывается деструктор. (Локальные объекты рассматривались в разделе 8.1.)
Например, следующий класс инкапсулирует выделение памяти для массива целых в конструкторе и ее освобождение в деструкторе:
class PTR {
public:
PTR() { ptr = new int[ chunk ]; }
~PTR { delete[] ptr; }
private:
int *ptr;
};
Локальный объект такого типа создается в функции manip() перед вызовом mathFunc():
void manip( int parm ) {
PTR localPtr;
// ...
mathFunc( parm ); // возбуждает исключение divideByZero
// ...
}
Если mathFunc() возбуждает исключение типа divideByZero, то начинается раскрутка стека. В процессе поиска подходящего catch-обработчика проверяется и функция manip(). Поскольку вызов mathFunc() не заключен в try-блок, то manip() нужного обработчика не содержит. Поэтому стек раскручивается дальше по цепочке вызовов. Но перед выходом из manip() с необработанным исключением процесс раскрутки уничтожает все объекты типа классов, которые локальны в ней и были созданы до вызова mathFunc(). Таким образом, локальный объект localPtr уничтожается до того, как поиск пойдет дальше, а следовательно, память, на которую он указывает, будет освобождена и утечки не произойдет.
Поэтому говорят, что процесс обработки исключений в C++ поддерживает технику программирования, основной принцип которой можно сформулировать так: “захват ресурса – это инициализация; освобождение ресурса – это уничтожение”. Если ресурс реализован в виде класса и, значит, действия по его захвату сосредоточены в конструкторе, а действия по освобождению – в деструкторе (как, например, в классе PTR выше), то локальный для функции объект такого класса автоматически уничтожается при выходе из функции в результате необработанного исключения. Действия, которые должны быть выполнены для освобождения ресурса, не будут пропущены при раскрутке стека, если они инкапсулированы в деструкторы, вызываемые для локальных объектов.
Класс auto_ptr, определенный в стандартной библиотеке (см. раздел 8.4), ведет себя почти так же, как наш класс PTR. Это средство для инкапсуляции выделения памяти в конструкторе и ее освобождения в деструкторе. Если для выделения одиночного объекта из хипа используется auto_ptr, то гарантируется, что при выходе из составной инструкции или функции из-за необработанного исключения память будет освобождена.
19.2.6. Спецификации исключений
С помощью спецификации исключений (см. раздел 11.4) в объявлении функции указывается множество исключений, которые она может возбуждать прямо или косвенно. Спецификация позволяет гарантировать, что функция не возбудит не перечисленные в ней исключения.
Такую спецификацию разрешается задавать для функций-членов класса так же, как и для обычных функций; она должна следовать за списком параметров функции-члена. Например, в определении класса bad_alloc из стандартной библиотеки C++ функции-члены имеют пустую спецификацию исключений throw(), т.е. гарантированно не возбуждают никаких исключений:
class bad_alloc : public exception {
// ...
public:
bad_alloc() throw();
bad_alloc( const bad_alloc & ) throw();
bad_alloc & operator=( const bad_alloc & ) throw();
virtual ~bad_alloc() throw();
virtual const char* what() const throw();
};
Отметим, что если функция-член объявлена с модификатором const или volatile, как, скажем, what() в примере выше, то спецификация исключений должна идти после него.
Во всех объявлениях одной и той же функции спецификации исключений обязаны содержать одинаковые типы. Если речь идет о функции-члене, определение которой находится вне определения класса, то спецификации исключений в этом определении и в объявлении функции должны совпадать:
#include
// определяет класс overflow_error
class transport {
// ...
public:
double cost( double, double ) throw ( overflow_error );
// ...
};
// ошибка: спецификация исключений отличается от той, что задана
// в объявлении в списке членов класса
double transport::cost( double rate, double distance ) { }
Виртуальная функция в базовом классе может иметь спецификацию исключений, отличающуюся от той, что задана для замещающей функции-члена в производном. Однако в производном классе эта спецификация для виртуальной функции должна накладывать не меньше ограничений, чем в базовом:
class Base {
public:
virtual double f1( double ) throw();
virtual int f2( int ) throw( int );
virtual string f3() throw( int, string );
// ...
}
class Derived : public Base {
public:
// ошибка: спецификация исключений накладывает меньше ограничений,
// чем на Base::f1()
double f1( double ) throw( string );
// правильно: та же спецификация исключений, что и для Base::f2()
int f2( int ) throw( int );
// правильно: спецификация исключений f3() накладывает больше ограничений
string f3( ) throw( int );
// ...
};
Почему спецификация исключений в производном классе должна накладывать не меньше ограничений, чем в базовом? В этом случае мы можем быть уверены, что вызов виртуальной функции из производного класса по указателю на тип базового не нарушит спецификацию исключений функции-члена базового класса:
// гарантируется, что исключения возбуждены не будут
void compute( Base *pb ) throw()
{
try {
pb->f3( ); // может возбудить исключение типа int или string
}
// обработка исключений, возбужденных в Base::f3()
catch ( const string & ) { }
catch ( int ) { }
}
Объявление f3() в классе Base гарантирует, что эта функция возбуждает лишь исключения типа int или string. Следовательно, функция compute() включает catch-обработчики только для них. Поскольку спецификация исключений f3() в производном классе Derived накладывает больше ограничений, чем в базовом Base, то при программировании в согласии с интерфейсом класса Base наши ожидания не будут обмануты.
В главе 11 мы говорили о том, что между типом возбужденного исключения и типом, заданным в спецификации исключений, не допускаются никакие преобразования. Однако если там указан тип класса, то функция может возбуждать исключения в виде объекта класса, открыто наследующего заданному. Аналогично, если имеется указатель на класс, то функции разрешено возбуждать исключения в виде указателя на объект класса, открыто наследующего заданному. Например:
class stackExcp : public Excp { };
class popObEmpty : public stackExcp { };
class pushOnFull : public stackExcp { };
void stackManip() throw( stackExcp )
{
// ...
}
Спецификация исключений указывает, что stackManip() может возбуждать исключения не только типа stackExcp, но также popOnEmpty и pushOnFull. Напомним, что класс, открыто наследующий базовому, представляет собой пример отношения ЯВЛЯЕТСЯ, т.е. является частным случае более общего базового класса. Поскольку popOnEmpty и pushOnFull – частные случаи stackExcp, они не нарушают спецификации исключений функции stackManip().
19.2.7. Конструкторы и функциональные try-блоки
Можно объявить функцию так, что все ее тело будет заключено в try-блок. Такие try-блоки называются функциональными. (Мы упоминали их в разделе 11.2.) Например:
int main() {
try {
// тело функции main()
}
catch ( pushOnFull ) {
// ...
}
catch ( popOnEmpty ) {
// ...
}
Функциональный try-блок ассоциирует группу catch-обработчиков с телом функции. Если инструкция внутри тела возбуждает исключение, то поиск его обработчика ведется среди тех, что следуют за телом функции.
Функциональный try-блок необходим для конструкторов класса. Почему? Определение конструктора имеет следующий вид:
имя_класса( список_параметров )
// список инициализации членов:
: член1(выражение1 ) , // инициализация член1
член2(выражение2 ) , // инициализация член2
// тело функции:
{ /* ... */ }
выражение1 и выражение2 могут быть выражениями любого вида, в частности функциями, которые возбуждают исключения.
Рассмотрим еще раз класс Account, описанный в главе 14. Его конструктор можно переопределить так:
inline Account::
Account( const char* name, double opening_bal )
: _balance( opening_bal - ServiceCharge() )
{
_name = new char[ strlen(name) + 1 ];
strcpy( _name, name );
_acct_nmbr = get_unique_acct_nmbr();
}
Функция ServiceCharge(), вызываемая для инициализации члена _balance, может возбуждать исключение. Как нужно реализовать конструктор, если мы хотим обрабатывать все исключения, возбуждаемые функциями, которые вызываются при конструировании объекта типа Account?
Помещать try-блок в тело функции нельзя:
inline Account::
Account( const char* name, double opening_bal )
: _balance( opening_bal - ServiceCharge() )
{
try {
_name = new char[ strlen(name) + 1 ];
strcpy( _name, name );
_acct_nmbr = get_unique_acct_nmbr();
}
catch (...) {
// специальная обработка
// не перехватывает исключения,
// возбужденные в списке инициализации членов
}
}
Поскольку try-блок не охватывает список инициализации членов, то catch-обработчик, находящийся в конце конструктора, не рассматривается при поиске кандидатов, которые способны перехватить исключение, возбужденное в функции ServiceCharge().
Использование функционального try-блока – это единственное решение, гарантирующее, что все исключения, возбужденные при создании объекта, будут перехвачены в конструкторе. Для конструктора класса Account такой try-блок можно определить следующим образом:
inline Account::
Account( const char* name, double opening_bal )
try
: _balance( opening_bal - ServiceCharge() )
{
_name = new char[ strlen(name) + 1 ];
strcpy( _name, name );
_acct_nmbr = get_unique_acct_nmbr();
}
catch (...) {
// теперь специальная обработка
// перехватывает исключения,
// возбужденные в ServiceCharge()
}
Обратите внимание, что ключевое слово try находится перед списком инициализации членов, а составная инструкция, образующая try-блок, охватывает тело конструктора. Теперь предложение catch(...) принимается во внимание при поиске обработчика исключения, возбужденного как в списке инициализации членов, так и в теле конструктора.
19.2.8. Иерархия классов исключений в стандартной библиотеке C++
В начале этого раздела мы определили иерархию классов исключений, с помощью которой наша программа сообщает об аномальных ситуациях. В стандартной библиотеке C++ есть аналогичная иерархия, предназначенная для извещения о проблемах при выполнении функций из самой стандартной библиотеки. Эти классы исключений вы можете использовать в своих программах непосредственно или создать производные от них классы для описания собственных специфических исключений.
Корневой класс исключения в стандартной иерархии называется exception. Он определен в стандартном заголовочном файле и является базовым для всех исключений, возбуждаемых функциями из стандартной библиотеки. Класс exception имеет следующий интерфейс:
namespace std {
class exception
public:
exception() throw();
exception( const exception & ) throw();
exception& operator=( const exception & ) throw();
virtual ~exception() throw();
virtual const char* what() const throw();
};
}
Как и всякий другой класс из стандартной библиотеки C++, exception помещен в пространство имен std, чтобы не засорять глобальное пространство имен программы.
Первые четыре функции-члена в определении класса – это конструктор по умолчанию, копирующий конструктор, копирующий оператор присваивания и деструктор. Поскольку все они открыты, любая программа может свободно создавать и копировать объекты-исключения, а также присваивать им значения. Деструктор объявлен виртуальным, чтобы сделать возможным дальнейшее наследование классу exception.
Самой интересной в этом списке является виртуальная функция what(), которая возвращает C-строку с текстовым описанием возбужденного исключения. Классы, производные от exception, могут заместить what() собственной версией, которая лучше характеризует объект-исключение.
Отметим, что все функции в определении класса exception имеют пустую спецификацию throw(), т.е. не возбуждают никаких исключений. Программа может манипулировать объектами-исключениями (к примеру, внутри catch-обработчиков типа exception), не опасаясь, что функции создания, копирования и уничтожения этих объектов возбудят исключения.
Помимо корневого exception, в стандартной библиотеке есть и другие классы, которые допустимо использовать в программе для извещения об ошибках, обычно подразделяемых на две больших категории: логические ошибки и ошибки времени выполнения.
Логические ошибки обусловлены нарушением внутренней логики программы, например логических предусловий или инвариантов класса. Предполагается, что их можно найти и предотвратить еще до начала выполнения программы. В стандартной библиотеке определены следующие такие ошибки:
namespace std {
class logic_error : public exception { // логическая ошибка
public:
explicit logic_error( const string &what_arg );
};
class invalid_argument : public logic_error { // неверный аргумент
public:
explicit invalid_argument( const string &what_arg );
};
class out_of_range : public logic_error { // вне диапазона
public:
explicit out_of_range( const string &what_arg );
};
class length_error : public logic_error { // неверная длина
public:
explicit length_error( const string &what_arg );
};
class domain_error : public logic_error { // вне допустимой области
public:
explicit domain_error( const string &what_arg );
};
<< Пред. стр. 95 (из 121) След. >>
Список литературы по разделу