Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 94
Текст из файла (страница 94)
) сагсЬ (Ьай айос) // как-нибудь реагируем на исчерпание памяти ) В функции орегагог пап() пеьг Ьалй!ег является указателем на функцию-обработчик, регистрируемую с помощью стандартной функции яе! пел Ьалй!ег(). Если мне нужно использовать для втой цели функцию гпу ле)о Ьалй!ег(), я могу напи- сатьс эег пен Ьалйгег(ьту иеьг Ьаий(ег) Если же еще и нужно перехватывать исключение Ьай ау!ос, то тогда следует написать такой код: го!й у'( ) ( юЫ(*оЫлЬ) () = эе! лтг Ьалйгег(ьту пеэг Ьапйег); Здесь я использую функцию та!!ос О из стандартной библиотеки языка С для выполнения поиска свободной памяти; другие реализации функции орегагог пе)г () могут избрать иные способы для выполнения такой работы.
Если память выделена, орегагог лельО может возвратить указатель на нее. В противном случае вызывается функция-обработчик лел Ьалй!ег(), призванная помочь отыскать дополнительный объем свободной памяти. Если она в атом преуспевает, то все прекрасно. Если нет — то обработчик не может просто вернуть управление, так как зто приведет к бесконечному циклу. Он должен сгенерировать исключение, предоставив вызывающей программе разбираться с проблемой: Глава 14. Обработка исключений 452 «у ! уу ...
) савел (Ьа«1 аггее) ) У... савел (... ) ! вег пе»е Ьапатее(оЫпЬ); Йеои т ) УУ вернуть обработчик УУ повторно сгенерировать исключение Бег пет лапа!ее(оЫая); УУ вернуть обработчик ) 14.4.6. Исключения в конструкторах Исключения решают проблему индикации ошибок в работе конструкторов.
Ввиду того, что конструкторы не возвращают никаких значений, традиционными альтернативами исключений являются следующие подходы; 1. Оставить создаваемый объект в нештатном состоянии, в надежде на проверку его состояния пользователем. 2. Установить значение нелокальной переменной (например, ееепо) для индикации об ошибке в работе конструктора, в надежде на проверку ее значения пользователем. А еще лучше вместо сагой (... ) использовать стратегию «получение ресурса есть инициализация» (см. 514.4) применительно к пеп Ьапатее (514.12[1]). При использовании пею Ьап«Иее никакой дополнительной информации не передается из места обнаружения ошибки в функцию-обработчик.
В принципе, передать дополнительную информацию не сложно. Но чем больше дополнительной информации при этом передается, тем больше взаимозависимость этих двух фрагментов кода. Это означает, что изменения в одном фрагменте требуют детального знания другого фрагмента, а может быть даже и изменения второго фрагмента. Поэтому для достижения минимума зависимости между фрагментами лучше ограничивать объем пересылаемой между ними информации. Механизм обработки исключений обеспечивает лучшую изоляцию фрагментов, чем механизм вызова функций-обработчиков, предоставляемых вызывающей стороной. Как правило, лучше организовать вьщеление ресурсов послойно (в разных уровнях абстракции), минимизируя зависимости одних слоев от помощи со стороны других (вызывающих) слоев. Опыт работы с крупными системами показывает, что они эволюционируют в указанном направлении.
Генерации исключений сопутствует создание объектов. Конкретные реализации в ситуации исчерпания памяти обязаны гарантировать создание объекта типа Ьа«1 аНос. Однако генерация иных исключений может приводить к полному исчерпанию памяти. ) 4,4. Управление ресурсами 453 3.
Не выполнять инициализацию в конструкторах, оставив эту работу для инициализирующих функций-членов, вызываемых пользователем до первого использования объекта. 4. Пометить объект как «непроинициализированный» и при первом вызове функции-члена для этого объекта выполнить инициализацию уже в этой функции (с вытекающими последствиями в случае невозможности успешного завершения инициализации).
Механизм обработки исключений позволяет передать вовне информацию о проблемах в работе конструкторов. Например, векторный класс может защитить свои обьекты от попыток затребовать слишком много памяти в момент их создания: с1азз Уесгог ( риЫ1с: с(азз Язе( ); еиит ( так=32000 ) ( Уесзог".: Уесгог((иг за) ( (г"(зг<0 ) ( тах<зг) зтзгош Язе О г // ... // ... ): Код, создающий объекты типа Уесгог, может перехватывать ошибки Уесгог:: Яге, чтобы сделать в этом случае что-нибудь осмысленное: Уесгог* /'((иг 1) ( ( Уесгог* р = иеш Уес1ог (1); // ... ге(ига р; ) сагой ( Уесгог:: Же) ( // обработка ошибки с размером ) ) Обработчик ошибок может использовать стандартный набор основных технологий сигнализирования об ошибках и восстановления.
При каждой передаче исключения в вызывающую функцию мнение о том, что же пошло не так, может различаться. Если передавать с исключением всю необходимую информацию, то объем исходных знаний об ошибке возрастает. Другими словами, главной задачей всех технологий обработки ошибок является передача информации об ошибке из точки ее возникновения в такую точку программы, где имеется достаточно сведений для выполнения удобным и надежным способом процесса восстановления системы от последствий возникновения ошибочных ситуаций. Глава 14. Обработка исключений 454 Применение стратегии «получение ресурса есть инициализация» является самым безопасным и элегантным способом обработки ошибок в конструкторах, запрашивающих несколько ресурсов (514.4). По сути, эта стратегия сводит работу с несколькими ресурсами к последовательному применению техники работы с единственным ресурсом.
14.4.6.1. Исключения и инициализация членов классов Что происходит, когда инициализирующий некоторый член класса код (прямо или косвенно) генерирует исключение? По умолчанию, исключение передается туда, откуда инициирован конструктор класса этого члена. Тем не менее, сам конструктор может перехватить исключение, если все его тело и список инициализации членов заключить в ггу-блок. Например: с(азз Х ( )'есгог чч // ... риЫ(с: Х((пг); // ... Х::Х((нг з) ггу : »(з) // инициализация г значением з ( // ...
сагой (гесгог::%хе) //исключения из г перехватываются здесь ( // ... ) 14.4.6.2. Исключения и копирование Как все конструкторы, копирукнций конструктор может сигнализировать о невозможности штатного исполнения генерацией исключения. Объект в этом случае не создается. Например, копирующему конструктору класса гесюг часто нужно выделять память и копировать в нее элементы (516.3.4, 5Е.3.2), и это может вызвать генерацию исключения. Перед генерацией исключения копирующему конструктору нужно освободить все занятые им ресурсы. Подробное обсуждение вопросов, связанных с управлением ресурсами и обработкой исключений для контейнерных классов, представлено в ВЕ.2 и 5Е.З. Копирующее присваивание похоже на копирующий конструктор в том отношении, что тоже может занимать ресурсы и завершаться генерацией исключения.
Перед генерацией исключения здесь нужно убедиться, что оба операнда операции находятся в корректном состоянии. В противном случае нарушаются требования стандартной библиотеки, и зто может привести к непредсказуемому поведению (5Е.2, $Е.З.З). 14.5. Исключения, не являющиеся ошибками 455 14.4.7. Исключения в деструкторах х::-х() ггу ( Х() ' сагал (...
) ( У что-нибудь делаем Вложет генерировать исключения Функция стандартной библиотеки ипсаияЫ ехсерпоп() из файла <ехсерпов> возвращает тгие, если исключение было сгенерировано, но еще не было перехвачено. Это позволяет программисту предпринимать разные действия в случаях, когда объект уничтожается нормальным образом, илн же в процессе раскрутки стека. 14.5. Исключения, не являющиеся ошибками Если мы предвидим возникновение исключений и перехватываем их для обработки таким образом, что конечное поведение программы при этом не страдает, то почему нужно в таких случаях считать исключения ошибками? Только потому, что программист считает их ошибками, а механизм обработки исключений рассматривает как механизм обработки ошибок.
С другой стороны, можно рассматривать механизм обработки исключений как еще одну управляющую структуру. Например: воЫ г щиеие<Х>ь а) ( уое(;; ) С точки зрения механизма обработки исключений деструктор может быть вызван двумя способами: 1. Нормальный вызов: в результате обычного выхода из области видимости (В10.4.3), или операции бе!ете (В10.4.5). 2. Вызов в процессе обработки исключения: в процессе раскрутки стека (В14.4) механизм обработки исключений приводит к выходу из области видимости, содержащей объект с деструктором. В последнем случае исключение не может исходить из самого деструктора, так как это считается ошибкой в работе механизма обработки исключений, приводящей к вызову вЫ:: сеет(пате() (В14.7).
В конце концов, ни механизм обработки исключений, ни деструкторы не в состоянии в общем случае определить, каким исключением пренебречь ради обработки другого исключения. Выход из деструктора путем генерации исключения также считается нарушением требований стандартной библиотеки (вЕ.2). Деструктор может обрабатывать исключения, которые генерируются вызываемыми им функциями. Например: Глава 14, Обработка исключений 456 ( Хт = д.де(О; //генерирует Етр(у, если диене пустой (етрЯ //...
сагой ( Диеие<Х>:: Етр(у) ( ге(иго; ) ) В этом примере есть свое очарование, ибо это как раз тот случай, когда невозможно определенным образом сказать, что тут ошибка, а что нет. Обработка исключений представляет собой менее структурированный механизм управления, нежели локальные управляющие структуры типа гу или уог, и он показывает меньшую эффективность в случае реальной генерации исключения. Поэтому использовать такой механизм стоит лишь тогда, когда более традиционные структуры управления либо неэлегантны, либо недопустимы.
Отметим также, что стандартная библиотека предоставляет очередь ()цеце для произвольных элементов без использования исключений (В)7.3.2). Применение исключений в качестве альтернативного варианта выхода из функции является элегантным приемом, например, для выхода из функций поиска— особенно в случае глубоко рекурсивного поиска в древовидных структурах. Например: го1йуп»( Тгее* р, соня е(кдпяь е) ( Ц'(и == р->яг) (пгот р; К(Р- >1еЯ /пг( (р- >(е/1, и); гу(р->г(яЫ) Тп» (р- >г(»3», е); ) //» найдено Тгее* у)и»(Тгее* р, со»магг/пдь е) ( Йу ( 1п»((р,е) г ' сагой ( Тгее д) ( ге(игп д; ) ге(иго О; //д->яг==е Рассмотренным применением исключений не стоит перебарщивать, ибо это ведет к запутанному коду.
Всегда лучше, по возможности, придерживаться традиционной трактовки — «обработка исключений есть обработка ошибок». В этом случае код явным образом разделяется на «обычный код» и «код обработки ошибок». Это сильно улучшает читаемость кода. Однако реальный мир ие расслаивается на очевидные подчасти столь же простым образом (и организация программ отражает и должна отражать этот факт).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
