Повторное возбуждение исключения
Может оказаться так, что в одном предложении catch не удалось полностью обработать исключение. Выполнив некоторые корректирующие действия, catch-обработчик может решить, что дальнейшую обработку следует поручить функции, расположенной “выше” в цепочке вызовов. Передать исключение другому catch-обработчику можно с помощью повторного возбуждения исключения. Для этой цели в языке предусмотрена конструкция
throw;
которая вновь генерирует объект-исключение. Повторное возбуждение возможно только внутри составной инструкции, являющейся частью catch-обработчика:
catch ( exception eObj ) {
if ( canHandle( eObj ) )
// обработать исключение
return;
else
// повторно возбудить исключение, чтобы его перехватил другой
// catch-обработчик
throw;
| }
При повторном возбуждении новый объект-исключение не создается. Это имеет значение, если catch-обработчик модифицирует объект, прежде чем возбудить исключение повторно. В следующем фрагменте исходный объект-исключение не изменяется. Почему?
enum EHstate { noErr, zeroOp, negativeOp, severeError };
void calculate( int op ) {
try {
// исключение, возбужденное mathFunc(), имеет значение zeroOp
mathFunc( op );
}
catch ( EHstate eObj ) {
// что-то исправить
// пытаемся модифицировать объект-исключение
eObj = severeErr;
// предполагалось, что повторно возбужденное исключение будет
// иметь значение severeErr
throw;
}
| }
Так как eObj не является ссылкой, то catch-обработчик получает копию объекта-исключения, так что любые модификации eObj относятся к локальной копии и не отражаются на исходном объекте-исключении, передаваемом при повторном возбуждении. Таким образом, переданный далее объект по-прежнему имеет тип zeroOp.
Чтобы модифицировать исходный объект-исключение, в объявлении исключения внутри catch-обработчика должна фигурировать ссылка:
catch ( EHstate &eObj ) {
// модифицируем объект-исключение
eObj = severeErr;
// повторно возбужденное исключение имеет значение severeErr
throw;
| }
Теперь eObj ссылается на объект-исключение, созданный выражением throw, так что все изменения относятся непосредственно к исходному объекту. Поэтому при повторном возбуждении исключения далее передается модифицированный объект.
Таким образом, другая причина для объявления ссылки в catch-обработчике заключается в том, что сделанные внутри обработчика модификации объекта-исключения в таком случае будут видны при повторном возбуждении исключения. (Третья причина будет рассмотрена в разделе 19.2, где мы расскажем, как catch-обработчик вызывает виртуальные функции класса.)
Перехват всех исключений
Иногда функции нужно выполнить определенное действие до того, как она завершит обработку исключения, даже несмотря на то, что обработать его она не может. К примеру, функция захватила некоторый ресурс, скажем открыла файл или выделила память из хипа, и этот ресурс необходимо освободить перед выходом:
void manip() {
resource res;
res.lock(); // захват ресурса
// использование ресурса
// действие, в результате которого возбуждено исключение
res.release(); // не выполняется, если возбуждено исключение
| }
Если исключение возбуждено, то управление не попадет на инструкцию, где ресурс освобождается. Чтобы освободить ресурс, не пытаясь перехватить все возможные исключения (тем более, что мы не всегда знаем, какие именно исключения могут возникнуть), воспользуемся специальной конструкцией, позволяющей перехватывать любые исключения. Это не что иное, как предложение catch, в котором объявление исключения имеет вид (...) и куда управление попадает при любом исключении. Например:
// управление попадает сюда при любом возбужденном исключении
catch (...) {
// здесь размещаем наш код
| }
Конструкция catch(...) используется в сочетании с повторным возбуждением исключения. Захваченный ресурс освобождается внутри составной инструкции в catch-обработчике перед тем, как передать исключение по цепочке вложенных вызовов в результате повторного возбуждения:
void manip() {
resource res;
res.lock();
try {
// использование ресурса
// действие, в результате которого возбуждено исключение
}
catch (...) {
res.release();
throw;
}
res.release(); // не выполняется, если возбуждено исключение
| }
Чтобы гарантировать освобождение ресурса в случае, когда выход из manip() происходит в результате исключения, мы освобождаем его внутри catch(...) до того, как исключение будет передано дальше. Можно также управлять захватом и освобождением ресурса путем инкапсуляции в класс всей работы с ним. Тогда захват будет реализован в конструкторе, а освобождение – в автоматически вызываемом деструкторе. (С этим подходом мы познакомимся в главе 19.)
Предложение catch(...) используется самостоятельно или в сочетании с другими catch-обработчиками. В последнем случае следует позаботиться о правильной организации обработчиков, ассоциированных с try-блоком.
Catch-обработчики исследуются по очереди, в том порядке, в котором они записаны. Как только найден подходящий, просмотр прекращается. Следовательно, если предложение catch(...) употребляется вместе с другими catch-обработчиками, то оно должно быть последним в списке, иначе компилятор выдаст сообщение об ошибке:
try {
stack.display();
for ( int ix = 1; ix < 51; ++x )
{
// то же, что и выше
}
}
catch ( pushOnFull ) { }
catch ( popOnEmpty ) { }
| catch ( ... ) { } // должно быть последним в списке catch-обработчиков
Упражнение 11.4
Объясните, почему модель обработки исключений в C++ называется невозвратной.
Упражнение 11.5
Даны следующие объявления исключений. Напишите выражения throw, создающие объект-исключение, который может быть перехвачен указанными обработчиками:
(a) class exceptionType { };
catch( exceptionType *pet ) { }
(b) catch(...) { }
(c) enum mathErr { overflow, underflow, zeroDivide };
catch( mathErr &ref ) { }
(d) typedef int EXCPTYPE;
| catch( EXCPTYPE ) { }
Упражнение 11.6
Объясните, что происходит во время раскрутки стека.
Упражнение 11.7
Назовите две причины, по которым объявление исключения в предложении catch следует делать ссылкой.
Упражнение 11.8
На основе кода, написанного вами в упражнении 11.3, модифицируйте класс созданного исключения: неправильный индекс, использованный в операторе operator[](), должен сохраняться в объекте-исключении и затем выводиться catch-обработчиком. Измените программу так, чтобы operator[]() возбуждал при ее выполнении исключение.
Спецификации исключений
По объявлениям функций-членов pop() и push() класса iStack невозможно определить, что они возбуждают исключения. Можно, конечно, включить в объявление подходящий комментарий. Тогда описание интерфейса класса в заголовочном файле будет содержать документацию возбуждаемых исключений:
class iStack {
public:
// ...
void pop( int &value ); // возбуждает popOnEmpty
void push( int value ); // возбуждает pushOnFull
private:
// ...
| };
Но такое решение несовершенно. Неизвестно, будет ли обновлена документация при выпуске следующих версий iStack. Кроме того, комментарий не дает компилятору достоверной информации о том, что никаких других исключений функция не возбуждает. Спецификация исключений позволяет перечислить в объявлении функции все исключения, которые она может возбуждать. При этом гарантируется, что другие исключения функция возбуждать не будет.
Такая спецификация следует за списком формальных параметров функции. Она состоит из ключевого слова throw, за которым идет список типов исключений, заключенный в скобки. Например, объявления функций-членов класса iStack можно модифицировать, добавив спецификации исключений:
class iStack {
public:
// ...
void pop( int &value ) throw(popOnEmpty);
void push( int value ) throw(pushOnFull);
private:
// ...
| };
Гарантируется, что при обращении к pop() не будет возбуждено никаких исключений, кроме popOnEmpty, а при обращении к push()–только pushOnFull.
Объявление исключения – это часть интерфейса функции, оно должно быть задано при ее объявлении в заголовочном файле. Спецификация исключений – это своего рода “контракт” между функцией и остальной частью программы, гарантия того, что функция не будет возбуждать никаких исключений, кроме перечисленных.
Если в объявлении функции присутствует спецификация исключений, то при повторном объявлении этой же функции должны быть перечислены точно те же типы. Спецификации исключений в разных объявлениях одной и той же функции не суммируются:
// два объявления одной и той же функции
extern int foo( int = 0 ) throw(string);
// ошибка: опущена спецификация исключений
| extern int foo( int parm ) { }
Что произойдет, если функция возбудит исключение, не перечисленное в ее спецификации? Исключения возбуждаются только при обнаружении определенных аномалий в поведении программы, и во время компиляции неизвестно, встретится ли то или иное исключение во время выполнения. Поэтому нарушения спецификации исключений функции могут быть обнаружены только во время выполнения. Если функция возбуждает исключение, не указанное в спецификации, то вызывается unexpected() из стандартной библиотеки C++, а та по умолчанию вызывает terminate(). (В некоторых случаях необходимо переопределить действия, выполняемые функцией unexpected(). Стандартная библиотека предоставляет механизм для этого. Подробнее см. [STRAUSTRUP97].)
Необходимо уточнить, что unexpected() не вызывается только потому, что функция возбудила исключение, не указанное в ее спецификации. Все нормально, если она обработает это исключение самостоятельно, внутри функции. Например:
void recoup( int op1, int op2 ) throw(ExceptionType)
{
try {
// ...
throw string("we're in control");
}
// обрабатывается возбужденное исключение
catch ( string ) {
// сделать все необходимое
}
| } // все хорошо, unexpected() не вызывается
Функция recoup() возбуждает исключение типа string, несмотря на его отсутствие в спецификации. Поскольку это исключение обработано в теле функции, unexpected() не вызывается.
Нарушения спецификации исключений функции обнаруживаются только во время выполнения. Компилятор не сообщает об ошибке, если в выражении throw возбуждается исключение неуказанного типа. Если такое выражение никогда не выполнится или не возбудит исключения, нарушающего спецификацию, то программа будет работать, как и ожидалось, и нарушение никак не проявится:
extern void doit( int, int ) throw(string, exceptionType);
void action ( int op1, int op2 ) throw(string) {
doit( op1, op2 ); // ошибки компиляции не будет
// ...
| }
doit() может возбудить исключение типа exceptionType, которое не разрешено спецификацией action(). Однако функция компилируется успешно. Компилятор при этом генерирует код, гарантирующий, что при возбуждении исключения, нарушающего спецификацию, будет вызвана библиотечная функция unexpected().
Пустая спецификация показывает, что функция не возбуждает никаких исключений:
extern void no_problem () throw();
Если же в объявлении функции спецификация исключений отсутствует, то может быть возбуждено исключение любого типа.
Между типом возбужденного исключения и типом исключения, указанного в спецификации, не разрешается проводить никаких преобразований:
int convert( int parm ) throw(string)
{
//...
if ( somethingRather )
// ошибка программы:
// convert() не допускает исключения типа const char*
throw "help!";
| }
Выражение throw в функции convert() возбуждает исключение типа строки символов в стиле языка C. Созданный объект-исключение имеет тип const char*. Обычно выражение типа const char* можно привести к типу string. Однако спецификация не допускает преобразования типов, поэтому если convert() возбуждает такое исключение, то вызывается unexpected(). Для исправления ошибки выражение throw можно модифицировать так, чтобы оно явно преобразовывало значение выражения в тип string:
throw string( "help!" );
Не нашли, что искали? Воспользуйтесь поиском по сайту:
©2015 - 2024 stydopedia.ru Все материалы защищены законодательством РФ.
|