исключение — Консистентный способ устранения сбоев библиотеки C ++
Я посмотрел вокруг на разных сайтах, и не могу найти никакого ответа на этот вопрос, кроме тех, которые, кажется, не будут работать. Как следует из названия, я пытаюсь найти способ отловить, если библиотека, над которой я работаю, дает сбой. У меня есть класс Root, который содержит экземпляры многих классов стиля менеджера, которые есть в моей библиотеке, и он освобождает экземпляры в своем деструкторе. Естественно, что менеджеры несут ответственность за довольно много данных, поэтому, если они не утилизированы должным образом, есть вероятность довольно неприемлемого, даже опасного уровня утечек памяти.
Мне известно, что при сбое программы ОС освобождает пространство стека для программы, но это не включает вызов деструкторов выделенных объектов. Это также не включает в себя удаление кучи, выделенной во время выполнения, и именно так я имею дело с большим объемом памяти в моей библиотеке, что восходит к проблеме широко распространенных утечек памяти.
Множество ответов, которые я встречаю на других сайтах, просто говорят о том, чтобы зарегистрировать функцию в atexit(), но эта функция не работает, если приложение падает. И, как указано выше, поскольку сбой не вызывает деструкторов, нет способа создать глобальный синглтон, который закрывает все, когда он уничтожается, что и было моей первоначальной идеей, как с этим бороться. Моя другая идея состояла в том, чтобы просто надеяться, что конечный пользователь библиотеки примет надлежащие меры предосторожности, чтобы избежать сбоев (через широкое использование исключения), но я чувствую, что это противоречит идее хорошо закодированной библиотеки, и, честно говоря, я думаю, он просит немного от конечного пользователя справиться с этим.
Поэтому я предполагаю, что мой вопрос TL; DR таков: есть ли способ, либо через стандартную функцию C ++, либо через какой-то класс менеджера, отловить, когда библиотека выходит из строя, и правильно с ней бороться?
РЕДАКТИРОВАТЬ: Кроме того, я бы действительно предпочел кросс-платформенный способ справиться с этим. Моя кодовая база интенсивно использует возможности C ++ 11, поэтому я программно ограничил используемые компиляторы до последних версий GCC и Clang.
Кроме того, у меня также есть пара классов, например, Logger, которые закрывают свой поток для файловой системы и распечатывают пару сообщений о состоянии выхода. У меня также есть трекер памяти, который сообщает о любых возможных утечках памяти в файл, но только в его деструкторе.
Решение
«Есть ли способ, либо с помощью стандартной функции C ++, либо с помощью какого-либо класса менеджера, отловить, когда происходит сбой библиотеки, и правильно с ней справиться?»
Самый краткий ответ на ваш вопрос, который я могу себе представить:
Придерживайтесь классов и категорий C ++ Стандартная обработка ошибок.
Как вы просите atexit()поведение хорошо определено в стандартная ссылка также.
Заметка Есть и другие механизмы обработки, такие как std::terminate_handler, которые позволяют вам обрабатывать исключительные ситуации прерывания переносимым и совместимым со стандартами способом.
И последнее, но не менее важное: может потребоваться установка некоторых (в зависимости от ОС) обработчики сигналов, догонять ошибки как так называемые ошибка сегментации (SIGSEV) поднят из-за переполнения стека или подобных вещей.
Другие решения
Итак, я думаю, мой вопрос TL; DR заключается в следующем: есть ли способ, либо через
стандартная функция C ++, или через какой-то класс менеджера, чтобы поймать
когда происходит сбой библиотеки и правильно с ней бороться?
При наличии таких вещей, как структурированная обработка исключений и различные ошибки сегментации и ошибки шины (стандарт не говорит ни о чем из этого), единственный способ предотвратить сбой приложения вашей библиотеки при сбое — это предоставить библиотеку через двоичный файл, который выполняет клиентская программа, и клиент должен отвечать за мониторинг, если клиентский процесс умирает.
Если вы хотите, чтобы библиотека была связана непосредственно с приложением пользователя ты ничего не можешь сделать чтобы быть абсолютно уверенным, что ошибка в вашей библиотеке не приведет к сбою приложения пользователя. Для этого предназначены тестовые наборы модулей, подсистем и систем. Имейте в виду, что если в вашей библиотеке произойдет сбой приложения, практически каждая известная мне операционная система освободит все выделенные ей ресурсы, поэтому вам не понадобится глобальный синглтон для освобождения динамической памяти: она будет автоматически запрашиваться ОС точка крушения.
В заключение отметим, что если библиотека аварийно завершает работу, процесс уже находится в плохом состоянии. Там нет никакого способа, которым вы можете безопасно выполнить любой код (например, что, если куча процесса повреждена) в точке, включая запись сообщений журнала или сброс статуса утечки памяти.