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