我正在编写一个类，用于保存图形的连接组件的状态，支持动态连接，并且每次删除或添加新边时，我都必须重新计算相邻组件以连接或拆分它们。
这些方法可以抛出的唯一异常是 std::bad_alloc 。我的任何依赖项都不会引发其他异常。因此，唯一可能的异常(exception)是由于 std::unordered_set<...>::insert 等方法缺乏内存。或std::deque<...>::push_back .
这使我的算法设计变得非常复杂，因为我必须处理本地数据以保存差异，然后根据这些缓存的修改将所有修改移动到范围明确的 try-catch 中。 block 。
可读性大大降低，并且思考和编写异常安全代码的时间增加了很多。此外，内存过量使用使得处理此异常变得毫无意义。
遇到这种情况你会怎么做？考虑到如果确实缺乏内存，您的代码可能无论如何都会失败，但可能稍后，整个程序也会失败，确保异常安全代码真的很重要吗？
那么，简而言之，考虑到正如一条评论指出的那样，同样的异常抛出机制也可能会耗尽内存，是否值得处理内存不足的异常？
最佳答案
正如您所建议的，尝试在进程中优雅地处理内存不足的情况是极其困难和不可能的，具体取决于您所运行的操作系统的内存行为。在许多操作系统(例如使用默认设置配置的 Linux)上，内存不足的情况可能会导致您的进程在没有任何警告或追索权的情况下被简单地终止，无论您的代码如何仔细地尝试处理 bad_alloc 异常。
我的建议是让您的应用程序启动一个子进程(即它可以将自己作为子进程启动，并使用一个特殊参数让子进程知道它是子进程而不是父进程)。然后父进程只是等待子进程退出，如果退出，则重新启动子进程。
这样做的优点是不仅能够从内存不足的情况中恢复，还可以帮助您从可能导致子进程崩溃或过早退出的任何其他问题中恢复。
关于c++ - 编写 "anti-lack of memory"异常安全代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57856496/