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

Вложенная обработка исключений

Да, вложение блоков try/catch разрешается, хотя пользоваться этой возможностью следует как можно реже, если только вы хотите сохранить дружеские отношения с персоналом сопровождения вашей программы.

try {

try { try {

Ненадежный фрагмент

catch(...) { }

catch(...) {

catch(...) {

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

Внешние исключения не перехватываются!

Вы можете перехватить любое исключение, инициированное посредством throw. Тем не менее, существуют и другие исключения, которые не удается перехватить переносимыми способами. Например, если пользователь применяет для завершения программы комбинацию клавиш с правым Ctrl, нет гарантии, что операционная система сгенерирует исключение, которое может быть перехвачено вашими обработчиками. Вообще говоря, обработка исключений относится только к исключениям, сгенерированным программой; все остальное непереносимо.

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

Одно из принципиальных достоинств стандартной схемы обработки исключений - раскрутка стека (unwinding the stack). При запуске исключения автоматически вызываются деструкторы всех стековых объектов между throw и catch.

void fn() throw(int) { Foo aFoo; Что-то не так! throw(bad news);

Когда возникает исключение, до передачи стека соответствующему обработчику будет вызван деструктор aFoo. Тот же принцип действует и для try-блока вызывающей стороны.

try {

Bar b;

fn(); Вызывает исключение

catch(int exception) {

Перед тем, как мы попадем сюда, будет вызван деструктор b

Вообще говоря, гарантируется вызов деструкторов всех стековых объектов, сконструированных с начала выполнения try-блока. Это может пригодиться для закрытия открытых файлов, предотвращения утечки памяти или для других целей. Тем не менее, дело не обходится без некоторых нюансов.

Уничтожаемые объекты

Гарантируется вызов деструкторов всех стековых объектов, сконструированных с начала выполнения try-блока, но и только. Например, допустим, что к моменту возникновения исключения был сконструирован массив. Деструкторы вызываются лишь для тех объектов массива, которые были сконструированы до возникновения исключения.

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

class TempFoo { private:

Foo* f; public:

TempFoo(Foo* aFoo) : f(aFoo) {} ~TempFoo() { delete f; }

try {

TempFoo tf(new Foo); и т.д.

catch(...) {

Foo уничтожается деструктором tf

Исключения во время конструирования

Рассмотрим следующий процесс конструирования: class Foo {...} class Bar : public Foo { private: A a;

B b;

public:

Bar();

Bar::Bar()

X x;

throw(bad news); Y y;

Если во время конструирования объекта произойдет исключение, деструкторы будут вызваны для тех компонентов (базовых классов и переменных), конструкторы которых были выполнены к моменту возникновения исключения. Конструирование Ваr к этому моменту еще не завершено. Тем не менее, конструкторы базовых классов (Foo) и переменных (а и b) уже отработали, поэтому их деструкторы будут вызваны до передачи исключения обработчику. По тем же причинам будет вызван деструктор локальной переменной x. Деструктор у не вызывается, поскольку переменная еще не сконструирована. Деструктор Bar тоже не вызывается, поскольку конструирование объекта не завершилось к моменту инициирования исключения.

Предположим, конструктор b инициирует исключение. В этом случае вызываются деструкторы Foo и а, но не деструкторы b, Bar и у.

Одни и те же принципы действуют как для стековых, так и для динамических объектов. Если исключение возникает при конструировании динамического объекта, вызываются точно те же деструкторы, что и для стековых объектов.

Порядок вызова деструкторов

Гарантируется, что порядок вызова деструкторов будет обратным порядку вызова конструкторов. Это относится как к локальным переменным, так и к переменным и базовым классам объектов.

Нестандартная обработка исключений

Многие библиотеки и некоторые компиляторы обрабатывают исключения нестандартным образом. Большинство имитирует парадигму try/catch с помощью макросов, но не организует правильной раскрутки стека за счет вызова деструкторов конструированных объектов. Некоторые реализации ориентированы на конкретные типы компьютеров и операционных систем.

К сожалению, многие компиляторы претендуют на стандартную обработку исключений, но не во всем следуют каноническим правилам. На своем горьком опыте я узнал, что обработку исключений желательно тестировать, если вы делаете нечто хоть сколько-нибудь нестандартное (даже если оно должно быть стандартным). Если вы окажетесь в подобной ситуации, окажите услугу всем нам: наймите разработчика такого компилятора якобы для серьезного проекта и заставьте его писать и отлаживать код обработки исключений для его собственного компилятора в течение ближайших пяти лет. А еще лучше, заставьте его перенести в свой компилятор код, идеально работающий на другом компиляторе.

Если по какой-либо причине вам придется заниматься нестандартной обработкой исключений, больше всего проблем вызовет освобождение памяти от динамических объектов, которые были созданы до возникновения исключения и внезапно стали недоступными переменным. Именно для этой цели используется 99% обработки исключений в реальной жизни, да еще изредка требуется закрыть открытые файлы. Вы можете либо создать хитроумные структуры данных, которые перемещают новые динамические объекты на верх стека и, следовательно, сохраняют их доступность, либо воспользоваться методикой сборки мусора, описанной в последней части книги. Оба подхода выглядят в равной степени отталкивающе, так что выбирайте сами.

Условные обозначения

В этой книге я не использую ключевые слова throw и catch, а вставляю общие комментарии в тех местах, где может возникнуть исключение. Такой подход упрощает работу с программой, если ваш компилятор не поддерживает стандартную обработку исключений. Если вы увидите что-нибудь вроде следующего фрагмента и располагаете стандартной обработкой исключений, мысленно превратите комментарий в блок throw:

f() {

if (poo1->Al1ocate(size) == NULL)

исключение - нехватка памяти