我的应用程序遇到了磁盘已满错误，不知何故，由于磁盘已满，引发了未处理的异常，导致set_terminate()处理程序被调用。
通常，我会在我的日志文件中获得某种堆栈跟踪，这样我就可以看到出了什么问题，但是，在这种情况下，由于磁盘已满，没有记录堆栈跟踪，并且不清楚程序是否由于以下原因而终止磁盘空间不足。
从最后写入磁盘的内容中读取我可以读取的内容，它似乎std::clog正在被写入，已设置为进入磁盘（已满的那个）。
我想知道使用operator<<to write toclog是否会导致抛出异常，如果是这样，可能会抛出什么异常？
此外，我对如何改进我的应用程序的想法很感兴趣，如果这种情况在未来再次发生，我可能会更新我的应用程序，以便更好地跟踪到底出了什么问题，这样我就可以知道磁盘已满并且不是应用程序的其他缺点。
然而，关键问题是检测故障，没有它，如何缓解的想法是没有用的。
在 Linux 中，您可以使用文件名 [在一个特殊的目录中？] 来创建您所在位置的踪迹 - 因为文件只使用通常有很多的“i-node 空间”。
另一种选择是创建一个大（ish）文件作为“紧急日志存储” - 如果磁盘已满，则打开您的紧急日志存储，并写入该文件。让它变成几兆字节，在现代磁盘上没有人会注意到，但它为您提供了足够的空间来转储您所在位置的上下文。
我不知道代码本身会发生什么的细节，但我想解决如何处理这种异常的问题。
从本质上讲，这种问题需要更多的日志记录。但是，您必须考虑日志记录机制是否是这里的问题。您需要有一个不依赖于磁盘的替代日志/报告系统。
您可以继续添加冗余层，但在我看来，在异常情况下失败的主数据库，再加上在更多异常情况下失败的备份对于大多数应用程序来说已经足够了。如果数据弹性是最重要的，那么您当然会监控您的资源并在处理应用程序时进行缓解（发出操作员警告或您选择作为后备机制的任何东西 - 例如备份假脱机空间等）。
一般来说，all ways up比较的成本nearly always up在成本和开发时间上也遵循 80/20 规则。