Когда является C++ оконечным обработчиком Right Thing(TM)?
Ленивые программисты - лучшие программисты
Ленивые программисты чаще всего находят способы уменьшить количество времени, затрачиваемое на написание кода (особенно много похожего или повторяющегося кода). Это часто приводит к инструментам и рабочим процессам, от которых могут выиграть другие разработчики в компании / команде.
По мере того, как разработчик сталкивается с подобными проектами, он может создавать инструменты для начальной загрузки процесса разработки (например, создание слоя DRM, который работает с парадигмами проектирования баз данных компании).
Кроме того, разработчики, подобные этим, часто используют некоторую форму генерации кода. Это означает, что все ошибки одного типа (например, генератор кода не проверял нулевые параметры во всех методах) часто можно исправить, исправив генератор, а не 50+ экземпляров этой ошибки.
Ленивому программисту может потребоваться еще несколько часов, чтобы вывести первый продукт за дверь, но это сэкономит вам месяцы.
3 ответа
Это просто оптимистично:
но для большинства ресурсов это должно обрабатываться ОС автоматически при выходе из процесса
Единственными ресурсами, которые ОС обрабатывает автоматически, являются " Файловые дескрипторы »и« Память »(и это может варьироваться в зависимости от ОС). Практически все остальные ресурсы (и если у кого-то есть список ресурсов, которые автоматически обрабатываются ОС I хотелось бы, чтобы ОС вручную освобождала его).
Лучше всего избегать выхода с помощью terminate () и пытаться контролируемое завершение работы, заставляя стек правильно раскручиваться. Это гарантирует, что все деструкторы вызываются правильно и ваши ресурсы высвобождаются (с помощью деструкторов).
Единственное, что я хотел бы сделать, это зарегистрировать проблему. Чтобы, когда это произошло, я мог вернуться и исправить код, чтобы это больше не повторилось. Мне нравится, когда мой код красиво раскручивает стек для освобождения ресурсов, но это мнение, что некоторые люди любят резкие остановки, когда дела идут плохо.
Мой список, когда вызывается terminate:
Обычно он вызывается, когда исключение механизм обработки не может найти обработчик для брошенного исключения. Вот некоторые конкретные примеры:
- Исключение ускользает от main ()
- Примечание. Реализация определяет, будет ли здесь раскручиваться стек. Таким образом, я всегда ловлю в основном, а затем повторно бросаю (если я не обрабатываю явно). Таким образом, я гарантирую раскручивание стека (на всех платформах) и при этом получаю все преимущества механизма обработки исключений ОС.
- Два исключения распространяются одновременно.
- Исключение ускользает от десатруктора, пока распространяется другое исключение.
- Вызываемое выражение генерирует исключение
- Исключение до или после main.
- Если исключение ускользает от конструктора / деструктора глобального объекта.
- Если исключение выходит из деструктора статической переменной функции. (т.е. будьте осторожны с конструкторами / деструкторами нелокального статического объекта)
- Исключение ускользает от функции, зарегистрированной с помощью atexit ().
- Повторное генерирование, когда в данный момент исключение не распространяется.
- Не внесенное в список исключение ускользает от метода / функции. который имеет список спецификаторов исключений.
- через неожиданный.
Я думаю, что правильным будет вопрос, как избежать вызовов обработчика завершения, а не когда его использовать.
Подобно утверждению, сделанному в ответе Мартина Йорка , единственное, что я делаю в настраиваемом обработчике завершения, - это журнал проблема, чтобы я мог идентифицировать и исправить неправильный код. Это единственный случай, когда я обнаружил, что использование настраиваемого обработчика завершения - это Right Thing .
Так как это определяется реализацией, будет ли развернут стек перед вызовом std :: terminate () , я иногда добавляю код для генерации обратной трассировки , чтобы определить местонахождение неперехваченное исключение 1 .
1) Мне кажется, это работает при использовании GCC на платформах Linux.