调试生产环境中的崩溃

Question

首先，我应该给你一些背景信息。所讨论的程序是一个用 C++ 实现的相当典型的服务器应用程序。在整个项目以及所有底层库中，错误管理都是基于 C++ 异常的。

我的问题与处理不可恢复的错误和/或程序员错误有关——“未经检查的”Java 异常的松散等效项，因为需要更好的并行。我对在生产环境中处理此类情况的常见做法特别感兴趣。

特别是对于生产环境，在存在上述类型的错误时，两个相互冲突的目标显得尤为突出：易于调试和可用性（就操作性能而言）。其中每一项都依次提出了具体的策略：

• 安装顶级异常处理程序来吸收所有未捕获的异常，从而确保持续可用性。不幸的是，这使得错误检查更加复杂，迫使程序员依赖细粒度的日志记录或其他代码“检测”技术。

• 尽可能猛烈地碰撞；这使得人们能够通过核心转储对导致错误的情况进行事后分析。当然，我们必须提供一种方法让系统在崩溃后及时恢复运行，而这可能绝非小事。

所以我最终得到了两个不成熟的解决方案；我希望在服务可用性和调试设施之间取得折衷。我缺少什么？

注意：我已将问题标记为 C++ 特定问题，因为我对适用于该问题的解决方案和特性感兴趣；尽管如此，我知道与其他语言/环境会有相当大的重叠。

Answer 1

如果错误不可恢复，则根据定义，应用程序在生产环境中无法执行任何操作来从错误中恢复。换句话说，顶层异常处理程序并不是真正的解决方案。即使应用程序显示一条友好的消息，如“访问冲突”、“可能的内存损坏”等，这实际上并不会提高可用性。

当应用程序在生产环境中崩溃时，您应该获取尽可能多的信息以进行事后分析（您的第二个解决方案）。

也就是说，如果您在生产环境中遇到不可恢复的错误，则主要问题是您的产品 QA 流程（缺乏），以及（早在这之前）编写不安全/未经测试的代码。

当您完成对此类崩溃的调查后，您不仅应该修复代码，还应该修复您的开发过程，以便不再可能发生此类崩溃（即，如果损坏是未初始化的指针写入，请检查您的代码库并初始化所有指针和很快）。