RAII против исключений

Вы НЕ СЛЕДУЕТ выбрасываете исключение из деструктора.

Примечание. Обновлено, чтобы отразить изменения в стандарте:

В C++ 03
Если исключение уже распространяется, приложение будет остановлено.

В C++ 11
Если деструктор - noexcept (по умолчанию), приложение будет завершено.

Следующее основано на C++ 11

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

Следующее основано на C++ 03

Под прекращением я подразумеваю немедленную остановку Разматывание стопки прекращается. Деструкторы больше не вызываются. Все плохое. См. Обсуждение здесь.

выбрасывание исключений из деструктора

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

Что касается возможности std :: uncaught_exception (), я указываю вам на Статья Херба Саттерса о том, почему это не работает

Вы можете определить, есть ли в настоящее время исключение в полете (например, мы находимся между блоками throw и catch, выполняя раскручивание стека, возможно, копируя объекты исключения или подобное), проверив

bool std::uncaught_exception()

Если он возвращает true, бросок в этот момент завершит программу. Если нет, бросок безопасен (или, по крайней мере, так же безопасен, как и когда-либо). Это обсуждается в разделах 15.2 и 15.5.3 ISO 14882 (стандарт C++).

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

Из исходного вопроса:

Now, deallocation (finalization, however you want to call it) can fail, in which case exceptions are really the only way to let anybody upstairs know of our deallocation problem

Отсутствие очистки ресурса указывает либо на:

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

2. Ошибка распределителя или недоработка в конструкции. Обратитесь к документации. Скорее всего, ошибка существует, чтобы помочь диагностировать ошибки программиста. См. Пункт 1 выше.

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

Например, в бесплатном магазине C++ есть безотказный оператор delete. Другие API (например, Win32) предоставляют коды ошибок, но не работают только из-за ошибки программиста или аппаратного сбоя, с ошибками, указывающими на такие условия, как повреждение кучи, двойное освобождение и т. д.

Что касается неустранимых неблагоприятных условий, возьмем соединение с БД. Если закрыть соединение не удалось, потому что соединение было разорвано - круто, готово. Не бросай! Разрыв соединения (должен) привести к закрытому соединению, поэтому больше ничего делать не нужно. Во всяком случае, запишите сообщение трассировки, чтобы помочь диагностировать проблемы использования. Пример:

class DBCon{
public:
  DBCon() { 
    handle = fooOpenDBConnection();
  }
  ~DBCon() {
    int err = fooCloseDBConnection();
    if (err){
      if (err == E_fooConnectionDropped){
        // do nothing.  must have timed out
      } else if (fooIsCriticalError(err)){
        // critical errors aren't recoverable.  log, save 
        //  restart information, and die
        std::clog << "critical DB error: " << err << "\n";
        save_recovery_information();
        std::terminate();
      } else {
        // log, in case we need to gather this info in the future,
        //  but continue normally.
        std::clog << "non-critical DB error: " << err << "\n";
      }
    }
    // done!
  }
};

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

Изменить-Добавить

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

vector<DBHandle> to_be_closed_later;  // startup reserves space

DBCon::~DBCon(){
  int err = fooCloseDBConnection();
  if (err){
    ..
    else if ( fooIsRetryableError(err) ){
      try{
        to_be_closed.push_back(handle);
      } catch (const bad_alloc&){
        std::clog << "could not close connection, err " << err << "\n"
      }
    }
  }
}

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

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

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

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

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

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

Каковы причины, по которым ваше разрушение может потерпеть неудачу? Почему бы не позаботиться о том, чтобы обработать их, прежде чем фактически разрушить?

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

• Выполняется транзакция. (Отметьте std :: uncaught_exception () - если true, откат, иначе фиксация - это наиболее вероятные желаемые действия, если у вас нет политики, которая гласит иначе, перед фактическим закрытием соединения.)
• Соединение разорвано. (Обнаруживать и игнорировать. Сервер откатится автоматически.)
• Другая ошибка БД. (Зарегистрируйте это, чтобы мы могли изучить и, возможно, обработать должным образом в будущем. Что может быть для обнаружения и игнорирования. А пока попробуйте выполнить откат и снова отключиться, игнорируя все ошибки.)

Если я правильно понимаю RAII (чего я, возможно, не знаю), все дело в его объеме. Так что это не значит, что вы все равно ХОТИТЕ, что транзакции длятся дольше, чем объект. Мне кажется разумным, что вы хотите обеспечить закрытие как можно лучше. RAII не делает это уникальным - даже без объектов (скажем, в C) вы все равно попытаетесь уловить все условия ошибок и справиться с ними как можно лучше (иногда их игнорируют). Все, что делает RAII, - это заставляет вас поместить весь этот код в одно место, независимо от того, сколько функций используют этот тип ресурса.

Вы смотрите на две вещи:

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

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

Исключения - это один из способов сообщить, что что-то не удалось, но, как вы говорите, существует ограничение языка C++, которое означает, что они не подходят для этого с помощью деструктора [*]. Возвращаемые значения - это еще один способ, но еще более очевидно, что деструкторы тоже не могут их использовать.

Итак, если вы хотите знать, были ли ваши данные записаны на диск, вы не можете использовать RAII для этого. Это не «уничтожает всю цель RAII», поскольку RAII все равно будет пытаться его записать, и он все равно освободит ресурсы, связанные с дескриптором файла (транзакция БД, что угодно). Он ограничивает возможности RAII - он не скажет вам, были ли данные записаны или нет, поэтому для этого вам нужна функция close(), которая может возвращать значение и / или генерировать исключение.

[*] Это тоже вполне естественное ограничение, присутствующее в других языках. Если вы думаете, что деструкторы RAII должны генерировать исключения, чтобы сказать «что-то пошло не так!», Тогда что-нибудь должен произойти, когда уже есть исключение в полете, то есть «что-то еще пошло не так даже до этого!». Я знаю, что языки, использующие исключения, не допускают одновременного выполнения двух исключений - язык и синтаксис просто не позволяют этого. Если RAII должен делать то, что вы хотите, тогда необходимо переопределить сами исключения, чтобы было разумно, чтобы в одном потоке было несколько ошибок одновременно, а два исключения распространялись наружу и вызывались два обработчика, по одному для обработки каждого.

Другие языки позволяют второму исключению скрывать первое, например, если в Java возникает блок finally. C++ в значительной степени говорит, что второй должен быть подавлен, иначе вызывается terminate (в некотором смысле подавляя оба). Ни в том, ни в другом случае более высокие уровни стека не информируются об обеих неисправностях. Что немного прискорбно, так это то, что в C++ вы не можете достоверно сказать, является ли еще одно исключение слишком большим (uncaught_exception не говорит вам об этом, он говорит вам что-то другое), поэтому вы даже не можете выбросить случай, когда там не уже исключение в полете. Но даже если бы вы могли сделать это в этом случае, вы все равно были бы напичканы тем, что еще один - это слишком много.