如何檢測由於磁盤已滿而未處理的異常？

Question

我的應用程序遇到磁盤滿錯誤，並且由於磁盤已滿而導致未處理的異常，導致調用set_terminate()處理程序。

通常情況下，我會在日誌文件中得到某種堆棧跟蹤，所以我可以看到出了什麼問題，但是，在這種情況下，因爲磁盤已滿，沒有堆棧跟蹤記錄，並且不清楚程序因缺少磁盤空間而終止。

從最後寫入磁盤的東西中讀取我所能得到的東西，看起來std::clog正在被寫入，它已被設置爲轉到磁盤（已滿）。

我想知道如果使用operator<<寫入clog可能會導致拋出異常，如果有的話可能拋出了什麼異常？

此外，我對如何改進我的應用程序的想法感興趣，以便如果這種情況在將來再次出現，我可能會更新我的應用程序，以留下更好的線索，以便我可以知道磁盤已滿，沒有其他應用程序的其他缺點。

但是，關鍵的問題是檢測失敗，沒有這個，如何緩解的想法是沒有用的。

Answer 1

在Linux中，你可以使用文件名[在一個特殊的目錄中？]來創建一個你所在的位置的路徑 - 因爲文件只使用「i節點空間」，而這通常很多。

另一種選擇是創建一個大的（ish）文件作爲「緊急日誌存儲」 - 如果磁盤已滿，則打開緊急日誌存儲並寫入該文件。把它做成幾兆字節，沒有人會注意到現代磁盤上，但它給你足夠的空間來傾倒你的位置。

Answer 2

我不知道在代碼本身會發生什麼的具體情況，但我想解決如何處理這種異常的問題。

本質上是這種問題，其中更多的日誌記錄是有用的。但是，您必須考慮記錄機制是否是這裏的問題。您需要有一個不依賴磁盤的替代日誌/報告系統。

你可以不斷添加冗餘層，但在我看來主要是在特殊情況下發生故障，加上在更特殊的情況下備份失敗是大多數應用足夠好。如果數據永續性是最重要的，那麼當然您應該監視您的資源並緩解（隨着應用程序的處理，問題操作員警告或您選擇的回退機制 - 例如備份假脫機空間等）。

一般而言，all ways up的成本與nearly always up的成本遵循80/20規則的成本和開發時間。