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

[zumm]

Аллоха, друзья.

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

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

Но что если метод close бросит исключение в деструкторе? Мы должны его поймать. Поймали. А что дальше? Проигнорировать? Вызвать std::terminate?

Есть ли какое-то устоявшиеся решение о том, что должно происходить в этом случае?

[Alex11223]

Читать 8 пункт Effective C++?

[zumm]

Сообщение от Alex11223

Читать 8 пункт Effective C++?

Chapter 8: Customizing new and delete. Этот раздел занимает 23 страницы в оригинале. Нельзя ли немного конкретики? Хотя бы в каком именно подразделе идет речь о озвученной проблеме? По их названиям мне не удается судить.

[Alex11223]

Я про Item, а не Chapter.

[zumm]

Сообщение от Alex11223

Я про Item, а не Chapter.

Ах, вот оно что. К сожалению, PDF, который мне удалось найти в гугле, как назло, начинается с Item 9. Страницы с 1 по 47 отсутствуют.

Не могли бы вы вкратце рассказать общую идею?

[Alex11223]

Сделать опциональный close кидающий исключение на случай если клиенту оно надо.
В деструкторе не кидать, а ловить и делать то, что надо, в зависимости от вашей задачи (лог и/или завершение, ...).

http://i.imgur.com/ehHbMIe.png

[zumm]

Ровно об этом я и написал в описании примера.

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

[Alex11223]

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

Ну и библиотеки разные бывают. Вполне может быть и доступен лог. Например может быть нормальным вариантом просто в поток ошибок писать (в дебаг режиме или отключаемо).

[zumm]

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

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

[Alex11223]

Нету более универсального, решать по ситуации.

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