C++. Сборник рецептов - читать бесплатно онлайн полную версию книги автора Д. Райан Стефенс (Глава 9 Исключения и безопасность) #10

Глава 9 Исключения и безопасность

9.0. Введение

Данная глава содержит рецепты по обработке исключений в С++. Язык C++ обеспечивает необходимую поддержку работы с исключениями, и, используя некоторые приемы, вы сможете создавать программный код, в котором исключительные ситуации эффективно обрабатываются и легко отлаживаются.

Первый рецепт описывает семантику C++ по выбрасыванию (throwing) и перехвату (catching) исключений и затем показывает, как создавать класс для представления исключений. Это является хорошей отправной точкой, если у вас мало или совсем нет опыта работы с исключениями. Здесь описываются также стандартные классы исключений, определенные в заголовочных файлах

Остальные рецепты иллюстрируют методы оптимального использования исключений и попутно вводят несколько важных терминов. Программное обеспечение не станет хорошим, если вы будете просто выбрасывать исключение, когда происходит что-нибудь неожиданное, или перехватывать исключение только для того, чтобы напечатать сообщение об ошибке и завершить программу аварийно. Для эффективного использования средств C++ по обработке исключений вам придется создавать программный код, который предотвращает утечку ресурсов и обеспечивает четкий режим работы при выбрасывании исключения. Эти условия известны как базовые и строгие гарантии безопасности исключений. Я описываю методы, которые позволят вам обеспечить эти гарантии для конструкторов и различных функций-членов.

9.1. Создание класса исключения

Проблема

Требуется создать свой собственный класс исключения, предназначенный для выбрасывания и перехвата исключений.

Решение

Вы можете выбрасывать (

throw

) или перехватывать (

catch

) любые типы С++, которые удовлетворяют некоторым простым требованиям, а именно имеют конструктор копирования и деструктор. Однако исключения являются сложными объектами, поэтому при проектировании класса, который представляет исключительные ситуации, необходимо рассмотреть ряд вопросов. Пример 9.1 показывает, каким может быть простой класс исключения.

Пример 9.1. Простой класс исключения

#include

#include

using namespace std;

class Exception {

public:

 Exception(const string& msg) : msg_(msg) {}

 ~Exception() {}

 string getMessage() const {return(msg_);}

private:

 string msg_;

};

void f() {

 throw(Exception("Mr. Sulu"));

int main() {

 try {

  f();

 } catch(Exception& e) {

  cout << "You threw an exception: " << e.getMessage() << endl;

Обсуждение

В языке C++ поддержка исключений обеспечивается при помощи трех ключевых слов:

try

catch

throw

. Они имеют следующий синтаксис.

try {

 // Что-нибудь, что может вызвать функцию "throw", например:

 throw(Exception("Uh-oh"));

} catch(Exception& e) {

 // Какие-нибудь полезные действия с объектом исключения е

Исключение в C++ (аналогично в Java и С#) - это способ, позволяющий поместить сообщение в бутылку, выбросить ее за борт и надеяться, что кто-нибудь пытается найти ваше сообщение где-нибудь ниже по стеку вызовов. Это является альтернативой другим, более простым методам, когда, например, возвращается код ошибки или выдается сообщение об ошибке. Семантика использования исключений (например, «попытка выполнения» каких-то действий, «выбрасывание» исключения с последующим его «перехватом») отличается от других операций С++, поэтому перед описанием способа создания класса исключения я кратко отвечу на вопрос, что представляет собой исключение и что значит выбросить и перехватить его.

Когда возникает исключительная ситуация и вы полагаете, что вызывающая программа должна быть осведомлена об этом, можете «поместить ваше сообщение в бутылку» в операторе

throw

, как показано ниже.

throw(Exception("Something went wrong"));

В результате среда времени выполнения сконструирует объект

Exception

(исключение), и затем начинается раскрутка стека вызовов до тех пор, пока не найдется блок

try

, в который был сделан вход, но из которого еще не сделан выход. Если среда времени выполнения не найдет такой блок, т.е. достигнет функции

main

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

terminate

. Но если блок

try

найден, то просматривается каждый оператор

catch

для данного блока

try

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

catch(Exception& е) { //...

В этом месте на основе выброшенного исключения создается новый объект

Exception

с помощью конструктора копирования класса

Exception

. (Объект исключения в области видимости

throw

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

catch

Если, находясь в теле оператора

catch

, вы хотите только что перехваченное исключение передать дальше, вы можете вызвать функцию

throw

без аргументов.

throw;

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

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

Exception

, содержащее указатель символьной строки или строку

string

, и затем выбрасывать его. Но такой класс не очень полезен, так как он мало чем отличается от класса-оболочки текстового сообщения. Собственно говоря, вы могли бы получить почти такой же результат, используя в качестве объекта исключения просто строку

string

try {

 throw(string("Something went wrong!"));

} catch (string& s) {

 cout << "The exception was: " << s << endl;

Нельзя сказать, что этот подход обязательно даст хорошие результаты; моя цель продемонстрировать основное свойство исключения: им может быть любой тип C++. В качестве исключений вы можете выбрасывать тип

int

char

class

struct

или любой другой тип C++, если действительно это потребуется. Но вам лучше использовать иерархию классов исключений, находящихся либо в стандартной библиотеке, либо ваших собственных.

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

. Базовым классом исключений в

является

exception

, который фактически определяется в

. На рис. 9.1 показана иерархия стандартных классов исключений.

Рис. 9.1. Иерархия стандартных классов исключений

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

logic_error

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

runtime_error

. Она предназначена для ситуаций, которые не всегда могут быть выявлены на этапе кодирования программы, например выход за пределы диапазона, переполнение или потеря значимости (underflow).

Это покрывает ограниченный набор исключительных ситуаций, и, вероятно, стандартные классы исключений имеют не все, что вам нужно. По-видимому, вам потребуется иметь исключения, более ориентированные на конкретные приложения, например

database_error

network_error

painting_error

и т.п. Мы обсудим это позже. А до этого давайте рассмотрим, как работают стандартные исключения.

Поскольку стандартная библиотека использует стандартные классы исключений (допустим это), можно ожидать, что классы из стандартной библиотеки будут их выбрасывать при возникновении проблемной ситуации, например при попытке использовать индекс, выходящий за пределы диапазона вектора

vector

std::vector v;

int i = -1;

// заполнить вектор v...

try {

 i = v.at(v.size()); // Выход на один элемент за конец вектора

} catch (std::out_of_range& е) {

 std::cerr << "Whoa, exception thrown: " << e.what() << '\n';

vector<>::at

выбросит исключение

out_of_range

, если вы используете индекс, значение которого меньше или больше, чем

size() - 1

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

catch(std::exception& е) {

 std::cerr << "Nonspecific exception: " << e.what() << '\n';

В результате будет перехватываться любой класс, производный от

exception

what

— это виртуальная функция-член, которая выдает строку сообщения, зависящую от реализации.

Я почти вернулся в исходную точку. Цель примера 9.1, который сопровождается продолжительным обсуждением, — иллюстрация достоинств класса исключения. Две вещи делают класс исключения полезным: иерархия, отражающая природу исключения, и сообщение, выдаваемое при перехвате исключения и предназначенное для пользователей программы. Иерархия классов исключений позволит разработчикам, использующим вашу библиотеку, создавать безопасный программный код и легко его отлаживать, а текст сообщения позволит тем же самым разработчикам предоставлять конечным пользователям приложения осмысленное сообщение об ошибке.

Исключения представляют собой сложную тему, и безопасная и эффективная обработка исключительных ситуаций является одной из самых трудных задач в проектировании программного обеспечения в целом и на языке C++ в частности. Каким должен быть конструктор, который не приведет к утечке памяти, если исключение выбрасывается в его теле или в списке инициализации? Что такое безопасное исключение? Я отвечу на эти и другие вопросы в последующих рецептах.

9.2. Создание безопасного при исключениях конструктора

Проблема

Ваш конструктор должен обеспечить базовые и строгие гарантии безопасности исключений. См. обсуждение, которое следует за определением «базовых» и «строгих» гарантий.

Решение

Используйте в конструкторе блоки

try

catch

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

Device

Broker

Broker

создает два объекта

Device

в динамической памяти (

heap

), но он должен правильно очистить память от этих объектов, если при конструировании выбрасывается исключение.

Пример 9.2. Безопасный при исключениях конструктор

#include

#include

using namespace std;

class Device {

public:

 Device(int devno) {

  if (devno == 2)

  throw runtime_error("Big problem");

 ~Device() {}

};

class Broker {

public:

 Broker (int devno1, int devno2) : dev1_(NULL), dev2_(NULL) {

  try {

  dev1_ = new Device(devno1); // Заключить операторы создания

  dev2_ = new Device(devno2); // объектов в динамической памяти в

                // блок try ...

  } catch (...) {

  delete dev1_; // ...очистить память и повторно

  throw;     // выбросить исключение, если что-то не

         // получилось.

 ~Broker() {

  delete dev1_;

  delete dev2_;

private:

 Broker();

 Device* dev1_;

 Device* dev2_;

};

int main() {

 try {

  Broker b(1, 2);

 } catch(exception& e) {

  cerr << "Exception: " << e.what() << endl;

Обсуждение

Сказать, что конструктор, функция-член, деструктор или что-нибудь другое «безопасно при исключениях», — значит гарантировать, что при их работе не будет утечки ресурсов и, вероятно, используемые ими объекты не будут находиться в противоречивом состоянии. В языке C++ такого рода гарантии названы базовыми и строгими.

Базовая гарантия безопасности при исключениях, которая интуитивно вполне понятна, означает, что при выбрасывании исключения текущая операция не приведет к утечке ресурсов и вовлеченный в операцию объект по-прежнему можно использовать (т.е. вы можете вызвать другие функции-члены и уничтожить объект, так как его состояние корректно). Это также означает, что программа находится в согласованном состоянии, хотя оно может быть непредсказуемым. Правила простые: если исключение выбрасывается где-нибудь в теле (например) функции-члена, созданные в динамической памяти объекты не лишаются поддержки, а вовлеченные в операцию объекты могут быть уничтожены или восстановлены в вызывающей программе. Другая гарантия, названная строгой гарантией безопасности исключений, обеспечивает неизменность состояния объекта, если операция завершается неудачно. Последнее относится к операциям, которые следуют после конструирования объекта, поскольку по определению объект, который выбрасывает исключение, всегда будет сконструирован не полностью и поэтому всегда будет иметь недостоверное состояние. Я вернусь к функциям-членам в рецепте 9.4. Теперь же давайте основное внимание уделим конструированию объектов.

В примере 9.2 определяется два класса,

Device

Broker

, которые делают не очень много, но с их помощью можно было бы легко представить любой сценарий работы пары устройство/брокер, когда вы имеете некоторый класс, который открывает соединение к каждому из двух устройств и управляет связью между ними. Брокер бесполезен, если доступно только одно устройство, поэтому семантика обработки транзакций при наличии брокера должна учитывать, что при выбрасывании исключения одним из двух этих устройств, когда делается попытка получения доступа к нему, должно освобождаться другое устройство. Это обеспечивает невозможность утечки памяти и других ресурсов.

Блоки

try

catch

сделают эту работу. В конструкторе заключите операторы по выделению динамической памяти для объекта в блок

try

и перехватывайте все исключения, которые выбрасываются в ходе конструирования этого объекта.

try {

 dev1_ = new Device(devno1);

 dev2_ = new Device(devno2);

} catch (...) {

 delete dev1_;

 throw;

Многоточие в обработчике

catch

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

Broker

, могла сделать что-то полезное с исключением, например записать куда-нибудь соответствующее сообщение об ошибке.

catch

-обработчике я удаляю лишь

dev1_

, так как последнее выбрасывание исключения возможно только в операторе

new

для

dev2_

. Если он выбрасывает исключение, то переменной

dev2_

не будет присвоено никакого значения и, следовательно, мне не нужно удалять объект

dev2_

. Однако, если вы что-то делаете после инициализации

dev2_

, вам потребуется выполнить зачистку этого объекта. Например:

try {

 dev1_ = new Device(devno1);

 dev2_ = new Device(devno2);

 foo_ = new MyClass(); // Может выбросить исключение

} catch (...) {

 delete dev1_;

 delete dev2_;

 throw;

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

NULL

не дает никакого эффекта. Другими словами, если присваивание значения переменной

dev1_

приводит к выбрасыванию исключения, ваш

catch

-обработчик все же выполнит оператор

delete dev2_

, однако все будет нормально, если вы инициализировали его значением

NULL

в списке инициализации.

Как я говорил в рецепте 9.1, рассматривая основы обработки исключений, для обеспечения гибкой стратегии обработки исключений может потребоваться особая ловкость, и то же самое относится к обеспечению безопасности исключений. Подробное рассмотрение методов проектирования программного кода, безопасного при исключениях, приводится в книге «Exceptional С++», написанной Гербом Саттером (Herb Sutter) (издательство «Addison Wesley»).

Смотри также

Рецепт 9.3.

9.3. Создание безопасного при исключениях списка инициализации

Проблема

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

Решение

Используйте специальный формат блоков

try

catch

, предназначенный для перехвата исключений, выбрасываемых в списке инициализации. Пример 9.3 показывает, как это можно сделать.

Пример 9.3. Обработка исключений в списке инициализации

#include

#include

using namespace std;

// Некоторое устройство

class Device {

public:

 Device(int devno) {

  if (devno == 2)

  throw runtime error("Big problem");

 ~Device() {}

private:

 Device();

};

class Broker {

public:

 Broker (int devno1, int devno2)

  try : dev1_(Device(devno1)), // Создать эти объекты в списке

  dev2_(Device(devno2)) {}   // инициализации

  catch (...) {

  throw; // Выдать сообщение в журнал событий или передать ошибку

      // вызывающей программе (см. ниже обсуждение)

 ~Broker() {}

private:

 Broker();

 Device dev1_;

 Device dev2_;

};

int main() {

 try {

  Broker b(1, 2);

 } catch(exception& e) {

  cerr << "Exception: " << e.what() << endl;

Обсуждение

Синтаксис обработки исключений в списках инициализации немного отличается от традиционного синтаксиса С++, потому что здесь блок

try

используется в качестве тела конструктора. Критической частью примера 9.3 является конструктор класса

Broker

Broker(int devno1, int devno2) // Заголовок конструктора такой же Constructor

 try :              // Действует так же, как try {...}

  dev1_(Device(devno1)),    // Затем идут операторы списка

  dev2_(Device(devno2)) {   // инициализации

  // Здесь задаются операторы тела конструктора.

  } catch (...) { // catch обработчик задается *после*

  throw; // тела конструктора

Режим работы блоков

try

catch

вполне ожидаем; единственное синтаксическое отличие от обычного блока

try

заключается в том, что при перехвате исключений, выброшенных из списка инициализации, за ключевым словом

try

идет двоеточие, затем список инициализации и после этого собственно блок

try

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

catch

-обработчиком, который расположен после тела конструктора. Вы можете при необходимости добавить в тело конструктора дополнительную пару блоков

try/catch

, однако вложенные блоки

try/catch

обычно выглядят непривлекательно.

Кроме перемещения операторов инициализации членов в список инициализации пример 9.3 отличается от примера 9.2 еще одним свойством. Объекты-члены

Device

на этот раз не создаются в динамической памяти с помощью оператора

new

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

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

delete

Но, возможно, вам требуется иметь члены, использующие динамическую память (или с ними вы предпочитаете иметь дело). Рассмотрим подход, используемый в первоначальном классе

Broker

в примере 9.2. Вы можете просто инициализировать ваши указатели в списке инициализации, не так ли?

class BrokerBad {

public:

 BrokerBad(int devno1, int devno2)

  try : dev1_(new Device(devno1)), // Создать объекты динамической

  dev2_(new Device(devno2)) {}   // памяти в списке инициализации

  catch (...) {

  if (dev1_) {

   delete dev1_; // He должно компилироваться и

   delete dev2_; // является плохим решением, если

  }        // все же будет откомпилировано

  throw; // Повторное выбрасывание того же самого исключения

 ~BrokerBad() {

  delete dev1_;

  delete dev2_;

private:

 BrokerBad();

 Device* dev1_;

 Device* dev2_;

};

Нет, так делать нельзя. Здесь две проблемы. Прежде всего, это не допустит ваш компилятор, потому что расположенный в конструкторе блок

catch

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

dev1_

выбрасывается исключение. Ниже дается программный код, который будет выполняться в

catch

-обработчике.

catch (...) {

 if (dev1_) { // Какое значение имеет эта переменная?

  delete dev1_; // в данном случае вы удаляете неопределенное значение

  delete dev2_;

 throw; // Повторное выбрасывание того же самого исключения

Если исключение выбрасывается в ходе конструирования

dev1_

, то оператором

new

не может быть возвращен адрес нового выделенного участка памяти и значение

dev1_

не меняется. Тогда что эта переменная содержит? Она будет иметь неопределённое значение, так как она никогда не инициализировалась. В результате, когда вы станете выполнять оператор

delete dev1_

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

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

NULL

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

delete

для

NULL

-указателей.

BrokerBetter(int devno1, int devno2) :

 dev1_(NULL), dev2_(NULL) {

  try {

  dev1_ = new Device(devno1);

  dev2_ = new Device(devno2);

  } catch (...) {

  delete dev1_; // Это сработает в любом случае

  throw;

Итак, вышесказанное можно подытожить следующим образом: если вам необходимо использовать члены-указатели, инициализируйте их значением

NULL

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

try/catch

. Вы можете освободить любую память в

catch

-обработчике. Однако, если допускается работа с автоматическими членами, сконструируйте их в списке инициализации и используйте специальный синтаксис блока

try/catch

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

Смотри также

Рецепт 9.2.

9.4. Создание безопасных при исключениях функций-членов

Проблема

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

Решение

Необходимо выяснить, какие операции могут выбрасывать исключения, и следует выполнить их первыми, обычно заключая в блок

try/catch

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

Пример 9.4. Безопасная при исключениях функция-член

class Message {

public:

 Message(int bufSize = DEFAULT_BUF_SIZE) :

  bufSize_(bufSize), initBufSize_(bufSize), msgSize_(0), buf_(NULL) {

  buf_ = new char[bufSize];

 ~Message() {

  delete[] buf_;

 // Добавить в конец символьные данные

 void appendData(int len, const char* data) {

  if (msgSize_+len > MAX_SIZE) {

  throw out_of_range("Data size exceeds maximum size.");

  if (msgSize_+len > bufSize_) {

  int newBufSize = bufSize_;

  while ((newBufSize *= 2) < msgSize_+len);

  char* p = new char[newBufSize]; // Выделить память

                  // для нового буфера

  copy(buf_, buf_+msgSize_, p);   // Скопировать старые данные

  copy(data, data+len, p+msgSize_); // Скопировать новые данные

  msgSize_ += len;

  bufSize_ = newBufSize;

  delete[] buf_; // Освободись старый буфер и установить указатель на

  buf_ = p;    // новый буфер

  } else {

  copy(data, data+len, buf_+msgSize_);

  msgSize_ += len;

 // Скопировать данные в буфер вызывающей программы

 int getData(int maxLen, char* data) {

  if (maxLen < msgSize_) {

  throw out_of_range("This data is too big for your buffer.");

  copy(buf_, buf_+msgSize_, data);

  return(msgSize_);

private:

 Message(const Message& orig) {}      // Мы рассмотрим эти операторы

 Message& operator=(const Message& rhs) {} // в рецепте 9.5

 int bufSize_;

 int initBufSize_;

 int msgSize_;

 char* buf_;

};

Обсуждение

Представленный в примере 9.4 класс

Message

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

appendData

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

Рассмотрим следующий фрагмент

appendData

if (msgSize_+len > bufSize_) {

 int newBufSize = bufSize_;

 while ((newBufSize *= 2) < msgSize_+len);

 char* p = new char[newBufSize];

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

new

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

bad_alloc

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

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

copy(buf_, buf_+msgSize_, p);

copy(data, data+len, p+msgSize_);

msgSize_ += len;

bufSize_ = newBufSize;

delete[] buf_;

buf_ = p;

Ни одна из этих операций не может выбросить исключение, поэтому нам не о чем волноваться. (Это происходит только из-за того, что буфер представляет собой последовательность символов; дополнительные разъяснения вы найдете при обсуждении примера 9.5.)

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

appendData

просто использует временную переменную для хранения нового размера буфера. Это решает проблему, связанную с размером буфера, но обеспечит ли это на самом деле базовую гарантию отсутствия утечки ресурсов? Обеспечит, но с трудом

сору

вызывает

operator=

для каждого элемента копируемой последовательности. В примере 9.4 каждый элемент имеет тип

char

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

copy

Предположим на секунду, что вместо «узкого» символьного буфера вам необходимо написать класс

Message

, который может содержать массив каких-то объектов. Вы могли бы представить его как шаблон класса, подобный представленному в примере 9.5.

Пример 9.5. Параметризованный класс сообщения

template

class MessageGeneric {

public:

 MessageGeneric(int bufSize = DEFAULT_BUF_SIZE) :

  bufSize_(bufSize), initBufSize_(bufSize), msgSize_(0), buf_(new T[bufSize]) {}

 ~MessageGeneric() {

  delete[] buf_;

 void appendData(int len, const data) {

  if (msgSize_+len > MAX_SIZE) {

  throw out of range("Data size exceeds maximum size.");

  if (msgSize_+len > bufSize_) {

  int newBufSize = bufSize_;

  while ((newBufSize *= 2) < msgSize_+len);

  T* p = new T[newBufSize];

  copy(buf_, buf_+msgSize_, p);   // Могут ли эти операторы

  copy(data, data+len, p+msgSize_); // выбросить исключение?

  msgSize_ += len;

  bufSize_ = newBufSize;

  delete[] buf_; // Освободить старый буфер и установить указатель на

  buf_ = p;    // новый буфер

  } else {

  copy(data, data+len, buf_+msgSize_);

  msgSize_ += len;

 // Скопировать данные в буфер вызывающей программы

 int getData(int maxLen, T* data) {

  if (maxLen < msgSize_) {

  throw out of range("This data is too big for your buffer.");

  copy(buf_, buf_+msgSize_, data);

  return(msgSize_);

private:

 MessageGeneric(const MessageGeneric& orig) {}

 MessageGeneric& operator=(const MessageGeneric& rhs) {}

 int bufSize_;

 int initBufSize_;

 int msgSize_;

 T* buf_;

};

Теперь вам необходимо быть более осторожным, так как вы заранее не знаете тип целевого объекта. Например, разве можно быть уверенным, что оператор

T::operator=

не выбросит исключение? Нельзя, поэтому вам необходимо учесть такую возможность. Заключите вызовы функций копирования в блок

try

try {

 copy(buf_, buf_+msgSize_, p);

 copy(data, data+len, p+msgSize_);

} catch(...) {

 // He имеет значения, какое исключение выбрасывается; все, что

 delete[] p; // мне необходимо сделать - это подчистить за собой,

 throw;    // а затем повторно выбросить исключение.

Поскольку оператор

catch

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

T::operator=

вы его перехватите и сможете освободить динамическую память, которая была только что распределена.

Строго говоря, функция

copy

в действительности ничего не выбрасывает, но это делает оператор

T::operator=

. Это происходит из-за того, что функция

copy

и остальные алгоритмы стандартной библиотеки в целом являются нейтральными по отношению к исключениям; это значит, что при выбрасывании исключений во время выполнения каких-либо внутренних операторов это исключение будет передано вызывающей программе, а не будет обработано полностью (перехвачено в блоке

catch

без повторного выбрасывания этого исключения). Это сохраняет возможность перехвата исключений в блоке

catch

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

Создание безопасных при исключениях функций-членов — трудоемкая работа. Для этого вам необходимо выявить все места, где могут выбрасываться исключения, и убедиться, что вы правильно их обрабатываете. Когда исключение может выбрасываться? При любом вызове функции. Операторы для встроенных типов данных не могут выбрасывать исключения, а деструкторы никогда не должны выбрасывать исключения, не все остальное, будь это отдельная функция, функция-член, оператор, конструктор и т.д., является потенциальным источником исключения. В приводимых примерах 9.5 и 9.6 в классах и функциях используются исключения с ограниченной областью действия. Классы содержат очень мало переменных-членов, и поведение класса носит дискретный характер. По мере увеличения количества функций-членов и переменных-членов, использования наследования и виртуальных функций задача обеспечения их строгой безопасности при исключениях становится более сложной.

Наконец, как и для большинства других требований, предъявляемых к программному обеспечению, вам требуется обеспечить только тот уровень безопасности исключений, который вам необходим. Другими словами, если вы создаете диалоговый мастер по генерации веб-страниц, график вашей разработки, вероятно, не позволит провести необходимое исследование и тестирование обеспечения в нем строгой безопасности исключений. Так, для вашего заказчика может быть приемлемой ситуация, когда пользователи встречаются иногда с сообщением о неопределенной ошибке: «Неизвестная ошибка, аварийное завершение программы» («Unknown error, aborting»). С другой стороны, если вы создаете программное обеспечение для управления углом ротора вертолета, ваш заказчик, вероятно, будет настаивать на обеспечении более существенных гарантий безопасности, чем вывод сообщения «Неизвестная ошибка, аварийное завершение программы».

9.5. Безопасное копирование объекта

Проблема

Требуется иметь безопасные при исключениях конструктор копирования и оператор присваивания базового класса.

Решение

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

Message

, который на этот раз содержит определения оператора присваивания и конструктора копирования.

Пример 9.6. Безопасные при исключениях оператор присваивания и конструктор копирования

#include

#include

const static int DEFAULT_BUF_SIZE = 3;

const Static int MAX_SIZE = 4096;

class Message {

public:

 Message(int bufSize = DEFAULT_BUF_SIZE) :

 bufSize_(bufSize), initBufSize_(bufSize), msgSize_(0), key_("") {

   buf_ = new char[bufSize]; // Примечание: теперь это делается в теле

               // конструктора

 ~Message() {

  delete[] buf_;

 // Безопасный при исключениях конструктор копирования

 Message(const Message& orig) :

  bufSize_(orig.bufSize_), initBufSize_(orig.initBufSize_),

  msgSize_(orig.msgSize_), key_(orig.key_) {

  // Эта функция может выбросить исключение

  buf_ = new char[orig.bufSize_]; // ...здесь может произойти то же

                  // самое

  copy(orig.buf_, orig.buf_+msgSize_, buf_); // Здесь нет

 // Безопасный при исключениях оператор присваивания использующий

 // конструктор копирования

 Message& operator=(const Message& rhs) {

  Message tmp(rhs); // Копировать сообщение во временную переменную,

           // используя конструктор копирования

  swapInternals(tmp); // Обменять значения переменных-членов и членов

            // временного объекта

  return(*this); // После выхода переменная tmp уничтожается вместе

          // с первоначальными данными

 const char* data() {

  return(buf_);

private:

 void swapInternals(Messages msg) {

  // Поскольку key_ не является встроенным типом данных, он может

  // выбрасывать исключение, поэтому сначала выполняем действия с ним

  swap(key_, msg.key_);

  // Если предыдущий оператор не выбрасывает исключение, то выполняем

  // действия со всеми переменными-членами, которые являются встроенными

  // типами

  swap(bufSize_, msg.bufSize_);

  swap(initBufSize_, msg.initBufSize_);

  swap(msgSize_, msg.msgSize_);

  swap(buf_, msg.buf_);

 int bufSize_;

 int initBufSize_;

 int msgSize_;

 char* buf;

 string key_;

Обсуждение

Вся работа здесь делается конструктором копирования и закрытой функцией-членом

swapInternals

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

Например, вы могли бы следующим образом выделить память под буфер в списке инициализации.

Message(const Message& orig) :

 bufSize_(orig bufSize_), initBufSize_(orig initBufSize_),

 msgSize_(orig.msgSize_), key_(orig.key_),

 buf_(new char[orig.bufSize_]) {

  copy(orig.buf_, orig.buf_+msgSize_, buf_);

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

new

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

int bufSize_;

int initBufSize_;

int msgSize_;

char* buf_;

string key_;

В результате

buf_

будет инициализироваться перед

key_

. Если при инициализации

key_

будет выброшено исключение,

buf_

не будет уничтожен, и у вас образуется участок недоступной памяти. От этого можно защититься путем использования в конструкторе блока

try/catch

(см. рецепт 9.2), но проще разместить оператор инициализации

buf_

в теле конструктора, что гарантирует его выполнение после операторов списка инициализации.

Выполнение функции

copy

не приведет к выбрасыванию исключения, так как она копирует элементарные значения. Но именно это место является тонким с точки зрения безопасности исключений: эта функция может выбросить исключение, если копируются объекты (например, если речь идет о контейнере, который параметризован типом своих элементов,

); в этом случае вам придется перехватывать исключение и освобождать связанную с ним память.

Вы можете поступить по-другому и копировать объект при помощи оператора присваивания,

operator=

. Поскольку этот оператор и конструктор копирования выполняют аналогичные действия (например, приравнивают члены моего класса к членам аргумента), воспользуйтесь тем, что вы уже сделали, и вы облегчите себе жизнь. Единственная особенность заключается в том, что вы можете сделать более привлекательным ваш программный код, используя закрытую функцию-член для обмена значений между данными-членами и временным объектом. Мне бы хотелось быть изобретателем этого приема, но я обязан отдать должное Гербу Саттеру (Herb Sutter) и Стефану Дьюхарсту (Stephen Dewhurst), в работе которых я впервые познакомился с этим подходом.

Возможно, вам все здесь ясно с первого взгляда, но я дам пояснения на тот случай, если это не так. Рассмотрим первую строку, в которой создается временный объект

tmp

с помощью конструктора копирования.

Message tmp(rhs);

В данном случае мы просто создали двойника объекта-аргумента. Естественно, теперь

tmp

эквивалентен

rhs

. После этого мы обмениваем значения его членов со значениями членов объекта

*this

swapInternals(tmp);

Вскоре я вернусь к функции

swapInternals

. В данный момент нам важно только то, что члены

*this

имеют значения, которые имели члены

tmp

секунду назад. Однако объект

tmp

представлял собой копию объекта

rhs

, поэтому теперь

*this

эквивалентен

rhs

. Но подождите: у нас по-прежнему имеется этот временный объект. Нет проблем, когда вы возвратите

*this

, tmp будет автоматически уничтожен вместе со старыми значениями переменных-членов при выходе за диапазон его видимости.

return(*this);

Все так. Но обеспечивает ли это безопасность при исключениях? Безопасно конструирование объекта

tmp

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

swapInternals

, поэтому рассмотрим, что в ней делается, и безопасны ли эти действия при исключениях.

Функция

swapInternals

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

swap

, которая принимает два аргумента a и b, создает временную копию a, присваивает аргумент b аргументу а и затем присваивает временную копию аргументу b. В этом случае такие действия являются безопасными и нейтральными по отношению к исключениям, так как источником исключений здесь могут быть только объекты, над которыми выполняются операции. Здесь не используется динамическая память и поэтому обеспечивается базовая гарантия отсутствия утечки ресурсов.

Поскольку объект

key_

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

key_

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

swapInternals

является в основном и строгом смысле безопасной при исключениях.

Однако возникает интересный вопрос. Что, если у вас имеется несколько объектов-членов? Если бы вы имели два строковых члена, начало функции

swapInternals

могло бы выглядеть следующим образом.

void swapInternals(Message& msg) {

 swap(key_, msg key_);

 swap(myObj_, msg.myObj_);

 // ...

Существует одна проблема: если вторая операция

swap

выбрасывает исключение, как можно безопасно отменить первую операцию

swap

? Другими словами, теперь

key_

имеет новое значение, но операция

swap

для

myObj_

завершилась неудачей, поэтому

key_

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

key_

во временную строку, но это не гарантирует безопасность, так как при копировании может быть выброшено исключение.

Одно из возможных решений состоит в использовании объектов, распределенных в динамической памяти.

void swapInternals(Message& msg) {

 // key имеет тип string*, a myObj_ - тип MyClass*

 swap(key_, msg.key_);

 swap(myObj_, msg.myObj_);

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

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

try/catch

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

Смотри также

Рецепт 9.2 и рецепт 9.3.