Когда можно сгенерировать исключение из деструктора в C ++?

Question

Я знаю, что правило НИКОГДА не бросать один во время деструктора, и я понимаю, почему. Я бы не посмел это сделать. Но даже C ++ Faq Lite говорит, что это правило хорошо в 99% случаев. В какие еще 1% они не в состоянии вникнуть?

Ссылка на пункт C ++ Faq Lite при броске из ~ ():

Answer 1

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

Все еще не делай этого.

Answer 2

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

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

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

Бывает, я работал на Маршалла Клайна, парня, который написал этот FAQ и преподавал C ++ из Книги FAQ; из-за этого я могу вам сказать, что вы немного неверно истолковали ответ. Он не говорит: «Ну и дела, это один случай, когда все будет хорошо, но я не собираюсь рассказывать вам об этом», - он говорит: «Я уверен, что если я скажу абсолютно и без исключения, с броска с дтор кто-нибудь когда-нибудь придумает один заурядный пример, который имеет смысл. Но я не знаю ни одного и не верю этому. Не пытайтесь делать это дома и проконсультируйтесь с адвокатом, никаких гарантий, явных или подразумеваемых. "

Answer 3

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

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

Answer 4

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

Answer 5

Полагаю, если бы вы могли надежно обнаружить действительно плохую ситуацию внутри деструктора, настолько плохую, что не было никакого хорошего способа справиться с этим, и вы должны были убедиться, что процесс остановлен СЕЙЧАС до того, как что-то еще произошло ... (представьте компьютер, подключенный к оружию или ядерной ракете), но на ум приходят две другие мысли:

1. Вместо того, чтобы вызывать исключение, было бы лучше вызвать exit () или abort () или TerminateProcess () или что-то, что явно останавливает вещи, вместо того, чтобы предполагать, что вы знаете, что компилятор превратит ваш исключение в деструкторе "в момент его компиляции.

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

Answer 6

Вы можете выбросить исключение из деструктора, если этот деструктор не вызывается автоматически при разматывании стека, или если исключение приведет к вызову terminate (). Чтобы определить, безопасно ли генерировать исключения из деструктора, используйте стандартную функцию uncaught_exception (); если он возвращает false, можно сгенерировать исключение

Answer 7

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

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