Как обнаружить необработанное исключение из-за переполнения диска?
Мое приложение столкнулось с ошибкой переполнения диска, и каким-то образом в результате переполнения диска возникло необработанное исключение, в результате чего set_terminate() вызываемый обработчик.
Обычно я получаю некоторую трассировку стека в моем файле журнала, чтобы я мог видеть, что пошло не так, однако, в этом случае, поскольку диск был заполнен, трассировка стека не была записана, и неясно, что программа завершилась из-за Недостаток места на диске.
Читая, что я могу из последних вещей, записанных на диск, он появляется std::clog был записан, который был настроен для перехода на диск (тот, который был заполнен).
Мне интересно, если использовать operator<< написать clog может ли быть вызвано исключение, и если да, то какое исключение могло быть выдано?
Кроме того, меня интересуют идеи о том, как улучшить мое приложение, чтобы в случае повторения этого условия в будущем я мог обновить свое приложение, чтобы оставить за собой лучшую информацию о том, что именно пошло не так, чтобы я мог знать, что диск заполнен и не какой-то другой недостаток приложения.
Тем не менее, ключевым вопросом является обнаружение сбоя, без которого идеи о том, как смягчить его, бесполезны.
Решение
В Linux вы можете использовать имена файлов [в специальном каталоге?], Чтобы создать след того, где вы были — поскольку файлы занимают только «пространство i-узла», которого обычно достаточно.
Другой вариант — создать большой (ish) файл в качестве «хранилища журналов аварийных ситуаций» — если диск заполнен, откройте хранилище журналов аварийных ситуаций и запишите в этот файл. Сделайте несколько мегабайт, и никто не заметит на современном диске, но он дает вам достаточно места для того, чтобы вывести контекст того, где вы были.
Другие решения
Я не знаю специфики того, что произойдет в коде как таковом, но я хотел бы рассмотреть вопрос о том, как обрабатывать такого рода исключения.
По сути, это проблема такого рода, когда было бы полезно больше журналировать. Однако вы должны рассмотреть, является ли механизм регистрации здесь проблемой. Вам понадобится альтернативная система регистрации / отчетности, которая не зависит от диска.
Вы можете продолжать добавлять уровни избыточности, но, по моему мнению, первичная база данных, которая дает сбой в исключительных обстоятельствах, в сочетании с резервной копией, которая дает сбой в еще более исключительных обстоятельствах, подходит для большинства приложений. Если устойчивость данных была первостепенной, то, конечно, вы будете контролировать свои ресурсы и снижать их (например, предупреждать оператора или что-то еще, что вы выбрали в качестве резервного механизма — например, резервное пространство в буфере и т. Д.) При обработке приложения.
В общем стоимость all ways up по сравнению с nearly always up также следует правилу 80/20 в отношении затрат и времени в разработке.