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

#include <iostream>

class Bad
{
    public:
        // Added the noexcept(false) so the code keeps its original meaning.
        // Post C++11 destructors are by default `noexcept(true)` and
        // this will (by default) call terminate if an exception is
        // escapes the destructor.
        //
        // But this example is designed to show that terminate is called
        // if two exceptions are propagating at the same time.
        ~Bad() noexcept(false)
        {
            throw 1;
        }
};
class Bad2
{
    public:
        ~Bad2()
        {
            throw 1;
        }
};


int main(int argc, char* argv[])
{
    try
    {
        Bad   bad;
    }
    catch(...)
    {
        std::cout << "Print This\n";
    }

    try
    {
        if (argc > 3)
        {
            Bad   bad; // This destructor will throw an exception that escapes (see above)
            throw 2;   // But having two exceptions propagating at the
                       // same time causes terminate to be called.
        }
        else
        {
            Bad2  bad; // The exception in this destructor will
                       // cause terminate to be called.
        }
    }
    catch(...)
    {
        std::cout << "Never print this\n";
    }

}

Это в основном сводится к:

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

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

Таким образом, вы перекладываете ответственность на пользователя. Если пользователь может исправить исключения, он будет вручную вызывать соответствующие функции и обрабатывать любые ошибки. Если пользователь объекта не беспокоится (поскольку объект будет уничтожен), то деструктору остается позаботиться о бизнесе.

Пример:

std :: fstream

Метод close () потенциально может вызвать исключение. Деструктор вызывает close (), если файл был открыт, но следит за тем, чтобы любые исключения не распространялись из деструктора.

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

У Скотта Майерса есть отличная статья на эту тему в своей книге «Эффективный C++».

Редактировать:

Видимо также в "Более эффективном C++"
Правило 11: не позволяйте исключениям оставлять деструкторы

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

Настоящий вопрос, который следует задать себе о выбросе из деструктора: «Что вызывающий может с этим делать?» Есть ли что-нибудь полезное, что вы можете сделать с исключением, что компенсировало бы опасности, создаваемые выбросом из деструктора?

Если я уничтожу объект Foo, а деструктор Foo выбросит исключение, что я могу с ним сделать? Я могу это записать или проигнорировать. Это все. Я не могу это «исправить», потому что объекта Foo уже нет. В лучшем случае я регистрирую исключение и продолжаю, как будто ничего не произошло (или завершаю программу). Стоит ли потенциально вызывать неопределенное поведение, выбрасывая его из деструктора?

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

Вы должны спросить в этой ситуации

int foo()
{
   Object o;
   // As foo exits, o's destructor is called
}

Что должно ловить исключение? Должен ли вызывающий foo? Или foo должен с этим справиться? Почему вызывающий foo должен заботиться о каком-то внутреннем объекте foo? Возможно, язык определит это так, чтобы это имело смысл, но это будет нечитабельным и трудным для понимания.

Что еще более важно, куда девается память для Object? Куда девается память, которой владеет объект? Он все еще выделен (якобы из-за сбоя деструктора)? Учтите также, что объект был в пространство стека, поэтому его явно не было.

Тогда рассмотрим этот случай

class Object
{ 
   Object2 obj2;
   Object3* obj3;
   virtual ~Object()
   {
       // What should happen when this fails? How would I actually destroy this?
       delete obj3;

       // obj 2 fails to destruct when it goes out of scope, now what!?!?
       // should the exception propogate? 
   } 
};

Когда удаление obj3 не удается, как мне на самом деле удалить, гарантированно не потерпев неудачу? Черт возьми, это моя память!

Теперь рассмотрим, что в первом фрагменте кода объект автоматически удаляется, потому что он находится в стеке, а Object3 находится в куче. Поскольку указатель на Object3 исчез, вы вроде SOL. У вас утечка памяти.

Вот один из безопасных способов сделать что-то:

class Socket
{
    virtual ~Socket()
    {
      try 
      {
           Close();
      }
      catch (...) 
      {
          // Why did close fail? make sure it *really* does close here
      }
    } 

};

Также смотрите этот Часто задаваемые вопросы

Выброс деструктора может привести к сбою, потому что этот деструктор может быть вызван как часть «раскрутки стека». Раскрутка стека - это процедура, которая выполняется при возникновении исключения. В этой процедуре все объекты, которые были помещены в стек с момента «попытки» и до тех пор, пока не было сгенерировано исключение, будут завершены -> будут вызваны их деструкторы. И во время этой процедуры другой выброс исключения не разрешен, потому что невозможно обработать два исключения одновременно, таким образом, это вызовет вызов abort (), программа выйдет из строя, и управление вернется в ОС.

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

Например:

class TempFile {
public:
    TempFile(); // throws if the file couldn't be created
    ~TempFile() throw(); // does nothing if close() was already called; never throws
    void close(); // throws if the file couldn't be deleted (e.g. file is open by another process)
    // the rest of the class omitted...
};

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

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

Проблема в том, что ни одна из проблем, которые он перечисляет с альтернативами, даже близко не так плоха, как поведение исключения, которое, давайте помнить, является «неопределенным поведением вашей программы». Некоторые из возражений автора включают «эстетически некрасиво» и «поощрять плохой стиль». Что бы вы предпочли? Программа с плохим стилем или с неопределенным поведением?

Из проекта ISO для C++ (ISO / IEC JTC 1 / SC 22 N 4411)

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

3 The process of calling destructors for automatic objects constructed on the path from a try block to a throw- expression is called “stack unwinding.” [ Note: If a destructor called during stack unwinding exits with an exception, std::terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. — end note ]

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

... но я верю, что деструкторы для классов контейнерного типа, такие как вектор, не должны маскировать исключения, возникающие из классов, которые они содержат. В этом случае я фактически использую метод «free / close», который вызывает себя рекурсивно. Да, сказал я рекурсивно. У этого безумия есть свой метод. Распространение исключения зависит от наличия стека: если возникает единственное исключение, то оба оставшихся деструктора все равно будут работать, а ожидающее исключение будет распространяться после возврата из подпрограммы, что прекрасно. Если возникает несколько исключений, то (в зависимости от компилятора) либо это первое исключение будет распространяться, либо программа завершится, что нормально. Если происходит так много исключений, что рекурсия переполняет стек, значит, что-то серьезно не так, и кто-то собирается об этом узнать, что тоже нормально. Лично я ошибаюсь в том, что ошибки раздуваются, а не являются скрытыми, секретными и коварными.

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

Q: So my question is this - if throwing from a destructor results in undefined behavior, how do you handle errors that occur during a destructor?

О: Есть несколько вариантов:

1. Позвольте исключениям вытекать из вашего деструктора, независимо от того, что происходит в другом месте. И при этом имейте в виду (или даже опасайтесь), что за ним может последовать std :: terminate.

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

3. моя любимая: Если std::uncaught_exception возвращает false, вы можете исключить утечку. Если он вернет true, то вернитесь к подходу регистрации.

Но хорошо ли бросать д'торс?

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

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

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

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

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

• (R) семантика выпуска (она же освобождает память)
• (C) Семантика совершить (также известный как файл румянец на диск)

Если мы рассмотрим вопрос таким образом, то я думаю, что можно утверждать, что семантика (R) никогда не должна вызывать исключение из dtor, поскольку нет: а) мы ничего не можем с этим поделать и б) многие операции с свободными ресурсами не вызывают даже предусмотреть проверку ошибок, например voidfree(void* p);.

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

Если мы будем следовать маршруту RAII и разрешить объекты, которые имеют семантику (C) в своих d'tors, я думаю, тогда мы также должны учесть нечетный случай, когда такие d'tors могут бросать. Отсюда следует, что вы не должны помещать такие объекты в контейнеры, а также следует, что программа все еще может terminate(), если commit-dtor выдает, пока активно другое исключение.

Что касается обработки ошибок (семантика фиксации / отката) и исключений, есть хороший разговор с одним Андрей Александреску: Обработка ошибок в C++ / декларативный поток управления (удерживаемым в НДЦ 2014)

В деталях он объясняет, как библиотека Folly реализует UncaughtExceptionCounter для своего инструментария ScopeGuard.

(Должен заметить, что у другие тоже были похожие идеи.)

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

В будущеемай будет стандартной функцией для этого, см. N3614, и обсуждение этого.

Upd '17: стандартная функция C++ 17 для этого - std::uncaught_exceptions afaikt. Я быстро процитирую статью cppref:

Notes

An example where int-returning uncaught_exceptions is used is ... ... first creates a guard object and records the number of uncaught exceptions in its constructor. The output is performed by the guard object's destructor unless foo() throws (in which case the number of uncaught exceptions in the destructor is greater than what the constructor observed)

Установите тревожное событие. Обычно тревожные события - лучшая форма уведомления о сбое при очистке объектов.

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

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

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

Мартин Ба (вверху) находится на правильном пути - вы по-разному проектируете логику RELEASE и COMMIT.

Для выпуска:

Тебе надо есть какие-то ошибки. Вы освобождаете память, закрываете соединения и т. д. Больше никто в системе не должен ВИДЕТЬ эти вещи снова, а вы возвращаете ресурсы ОС. Если похоже, что здесь вам нужна реальная обработка ошибок, это, вероятно, является следствием конструктивных недостатков вашей объектной модели.

Для фиксации:

Здесь вам нужны такие же объекты-оболочки RAII, которые такие вещи, как std :: lock_guard, предоставляют для мьютексов. С ними вы ВООБЩЕ не помещаете логику фиксации в dtor. У вас есть специальный API для этого, а затем объекты-оболочки, которые будут передавать его в СВОИх dtors и обрабатывать там ошибки. Помните, что вы можете просто ЛОВИТЬ исключения в деструкторе; их выдача смертельно опасна. Это также позволяет вам реализовать политику и различную обработку ошибок, просто создав другую оболочку (например, std :: unique_lock против std :: lock_guard), и гарантирует, что вы не забудете вызвать логику фиксации, которая является единственной половиной пути достойное обоснование для того, чтобы поставить его в дтор на 1 место.

Я нахожусь в группе, которая считает, что добавление паттерна «scoped guard» в деструктор полезно во многих ситуациях - особенно для модульных тестов. Однако имейте в виду, что в C++ 11 добавление деструктора приводит к вызову std::terminate, поскольку деструкторы неявно аннотируются с помощью noexcept.

Анджей Кшеменски написал отличный пост на тему деструкторов, которые бросают:

• https://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/

Он указывает, что в C++ 11 есть механизм для переопределения noexcept по умолчанию для деструкторов:

In C++11, a destructor is implicitly specified as noexcept. Even if you add no specification and define your destructor like this:

  class MyType {
        public: ~MyType() { throw Exception(); }            // ...
  };

The compiler will still invisibly add specification noexcept to your destructor. And this means that the moment your destructor throws an exception, std::terminate will be called, even if there was no double-exception situation. If you are really determined to allow your destructors to throw, you will have to specify this explicitly; you have three options:

• Explicitly specify your destructor as noexcept(false),
• Inherit your class from another one that already specifies its destructor as noexcept(false).
• Put a non-static data member in your class that already specifies its destructor as noexcept(false).

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

So my question is this - if throwing from a destructor results in undefined behavior, how do you handle errors that occur during a destructor?

Основная проблема вот в чем: нельзя не потерпеть неудачу. В конце концов, что значит потерпеть неудачу? Если фиксация транзакции в базе данных не удалась, и она не завершилась неудачей (не удалось выполнить откат), что произойдет с целостностью наших данных?

Поскольку деструкторы вызываются как для нормального, так и для исключительного (сбойного) пути, они сами не могут дать сбой, иначе мы «не сработаем».

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

The pragmatic solution is perhaps just make sure that the chances of failing on failure are astronomically improbable, since making things impossible to fail to fail can be almost impossible in some cases.

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

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

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

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

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

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