Когда обработчик завершения C ++ является правильной вещью (TM)?

Это просто оптимистично:

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

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

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

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

Мой список того, когда называется завершение:

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

• An exception escapes main()
  • Note: It is implementation defined whether the stack is unwound here. Thus I always catch in main and then rethrow (if I do not explicitly handle). That way I guarantee unwinding of the stack (across all platforms) and still get the benefits of the OS exception handling mechanism.
• Two exceptions propagating simultaneously.
  • An exception escapes a desatructor while another exception is propagating.
  • Выбрасываемое выражение генерирует исключение
• An exception before or after main.
  • If an exception escapes the constructor/destructor of a global object.
  • Если исключение ускользает от деструктора статической переменной функции. (т.е. будьте осторожны с конструкторами / деструкторами нелокального статического объекта)
  • Исключение ускользает от функции, зарегистрированной с помощью atexit ().
• Повторный выброс, если в настоящее время не распространяется исключение.
• An unlisted exception escapes a method/function that has exception specifier list.
  • via unexpected.

Подобно заявлению, сделанному в Мартина Йорка answer, единственное, что я делаю в настраиваемом обработчике прерывания, - это записываю проблему в журнал, чтобы я мог идентифицировать и исправить ошибочный код. Это единственный случай, когда я обнаружил, что использование настраиваемого обработчика прерывания является правильным решением.

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

^{1) Мне кажется, это работает при использовании GCC на платформах Linux.}

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