7

我目前正在为我的 OSS 应用程序添加异常和异常处理。异常从一开始就是一个普遍的想法，但我想找到一个好的异常框架，老实说，在开始使用它们之前更好地理解 C++ 异常处理约定和习语。我在 C#/.Net、Python 和其他使用异常的语言方面拥有丰富的经验。我对这个想法并不陌生（但远非大师）。

在 C# 和 Python 中，当发生未处理的异常时，用户会得到一个很好的堆栈跟踪，通常会得到很多非常有用的无价调试信息。如果您正在开发 OSS 应用程序，那么让用户将该信息粘贴到问题报告中是……好吧，让我们说我发现没有它就很难生活。对于这个 C++ 项目，我得到“应用程序崩溃”，或者来自更知情的用户，“我做了 X、Y 和 Z，然后它崩溃了”。但我也想要调试信息！

我已经（并且非常困难地）接受了这样一个事实，即我永远不会看到获取 C++ 异常堆栈跟踪的跨平台和跨编译器方式，但我知道我可以获得函数名称和其他相关信息。

而现在我想要我未处理的异常。我正在使用boost::exception，他们有这个非常好的diagnostic_information thingamajig 可以打印出（未损坏的）函数名、文件、行，最重要的是，程序员添加到该异常中的其他异常特定信息。

自然，我会尽可能地处理代码中的异常，但我并没有天真地认为我不会让一对夫妇溜走（当然是无意的）。

所以我想要做的是将我的主要入口点包装在一个try块中，该块catch创建一个特殊的对话框，通知用户应用程序中发生了错误，当用户单击“更多”或“调试”时显示更详细的信息信息”或其他。这将包含来自诊断信息的字符串。然后我可以指示用户将此信息粘贴到问题报告中。

但是一种烦人的直觉告诉我，将所有内容都包装在 try 块中是一个非常糟糕的主意。我要做的事是愚蠢的吗？如果是（即使不是），有什么更好的方法来实现我想要的？

4

4 回答 4

33

在 main() 中放置一个 try/catch 块是可以的，它不会导致任何问题。无论如何，该程序因未处理的异常而死。但是，这对您获取最重要的堆栈跟踪完全没有帮助。当 catch 块捕获异常时，该信息是奇闻趣事。

捕获 C++ 异常也不会很有帮助。程序死于从 std::exception 派生的异常的可能性非常小。虽然它可能发生。在 C/C++ 应用程序中，由于硬件异常而死亡的可能性更大，AccessViolation 是 numero uno。捕获这些需要在 main() 方法中使用 __try 和 __except 关键字。同样，可用的上下文非常少，您基本上只有一个异常代码。AV 还会告诉您哪个确切的内存位置导致了异常。

顺便说一句，这不仅仅是一个跨平台问题，您无法在任何平台上获得良好的堆栈跟踪。没有可靠的方法来遍历堆栈，有太多的优化（如帧指针遗漏）使这成为一个危险的旅程。这是 C/C++ 的方式：让它尽可能快，当它爆炸时不知道发生了什么。

您需要做的是用 C/C++ 方式调试这类问题。您需要创建一个小型转储。它大致类似于旧的“核心转储”，即异常发生时进程映像的快照。那时，你实际上得到了一个完整的核心转储。已经取得了进展，现在它是“迷你”的，有点必要，因为完整的核心转储将需要接近 2 GB 的空间。它实际上可以很好地诊断程序状态。

在 Windows 上，从调用 SetUnhandledExceptionFilter() 开始，您提供了一个回调函数指针，该指针指向一个函数，当您的程序因未处理的异常而终止时将运行该函数。任何例外，C++ 以及 SEH。您的下一个资源是 dbghelp.dll，可在 Debugging Tools for Windows 下载中获得。它有一个名为 MiniDumpWriteDump() 的入口点，它创建一个小型转储。

一旦你得到了 MiniDumpWriteDump() 创建的文件，你就非常成功了。您可以在 Visual Studio 中加载 .dmp 文件，就像它是一个项目一样。按 F5 和 VS 磨了一会儿，试图为进程中加载​​的 DLL 加载 .pdb 文件。您需要设置符号服务器，这对于获得良好的堆栈跟踪非常重要。如果一切正常，您将在引发异常的确切位置获得“调试中断”。带有堆栈跟踪。

为了使这项工作顺利进行，您需要做的事情：

  • 使用构建服务器创建二进制文件。它需要将调试符号（.pdb 文件）推送到符号服务器，以便在调试 minidump 时随时可用。
  • 配置调试器，以便它可以找到所有模块的调试符号。您可以从 Microsoft 获取 Windows 的调试符号，您的代码的符号需要来自上述符号服务器。
  • 编写代码以捕获未处理的异常并创建小型转储。我提到了 SetUnhandledExceptionFilter() 但创建 minidump 的代码不应该在崩溃的程序中。它可以成功编写小型转储的可能性很小，程序的状态未确定。最好的办法是运行一个“守卫”进程来监视一个命名的 Mutex。您的异常过滤器可以设置互斥锁，守卫可以创建小型转储。
  • 为小型转储创建一种从客户端机器转移到您的机器的方法。为此，我们使用 Amazon 的 S3 服务，以合理的速率传输 TB。
  • 将 minidump 处理程序连接到调试数据库。我们使用 Jira，它有一个 Web 服务，允许我们根据具有相同“签名”的早期崩溃数据库验证崩溃存储桶。当它是唯一的，或者没有足够的命中时，我们要求崩溃管理器代码将小型转储上传到亚马逊并创建错误数据库条目。

嗯，这就是我为我工作的公司所做的。效果很好，它将崩溃桶的频率从数千减少到数十。给开源 ffdshow 组件创建者的个人信息：我非常讨厌你。但是您不再使我们的应用程序崩溃了！臭虫。

于 2009-12-26T22:48:11.430 回答
3

将所有代码包装在一个try/catch块中是可以的。例如，它不会减慢其中任何内容的执行速度。事实上，我所有的程序都有（代码类似于）这个框架：

int execute(int pArgc, char *pArgv[])
{
    // do stuff
}

int main(int pArgc, char *pArgv[])
{
    // maybe setup some debug stuff,
    // like splitting cerr to log.txt

    try
    {
        return execute(pArgc, pArgv);
    }
    catch (const std::exception& e)
    {
        std::cerr << "Unhandled exception:\n" << e.what() << std::endl;
        // or other methods of displaying an error

        return EXIT_FAILURE;
    }
    catch (...)
    {
        std::cerr << "Unknown exception!" << std::endl;

        return EXIT_FAILURE;
    }
}
于 2009-12-26T22:04:22.517 回答
1

不，这并不愚蠢。这是一个非常好的主意，当然，在您遇到未处理的异常之前，它在运行时几乎没有任何成本。

请注意，已经有一个异常处理程序包装了您的线程，由操作系统提供（我认为另一个由 C 运行时提供）。您可能需要将某些异常传递给这些处理程序以获得正确的行为。在某些架构中，访问未对齐的数据由异常处理程序处理。所以你可能想要特殊情况EXCEPTION_DATATYPE_MISALIGNMENT并让它传递给更高级别的异常处理程序。

我包括寄存器、应用程序版本和内部版本号、异常类型和十六进制的堆栈转储，其中注释了模块名称和十六进制值的偏移量，这些值可能是代码的地址。请务必包含您的 exe 的版本号和内部版本号/日期。

您还可以VirtualQuery很容易地将堆栈值转换为“ModuleName+Offset”。而且，结合 .MAP 文件通常会告诉您确切的崩溃位置。

我发现我可以训练 beta 测试人员很容易地发送我的文本，但在早期，我得到的是错误对话框的图片而不是文本。我认为这是因为很多用户不知道您可以右键单击任何编辑控件以获取带有“全选”和“复制”的菜单。如果我要再做一次，我会添加一个按钮，将该文本复制到剪贴板，以便可以轻松地将其粘贴到电子邮件中。

如果您想麻烦使用“发送错误报告”按钮，那就更好了，但只是为用户提供一种将文本输入到他们自己的电子邮件中的方法可以让您大部分时间到达那里，并且不会引发任何危险信号关于“我与他们分享什么信息？”

于 2009-12-26T22:32:28.683 回答
0

事实上， boost::diagnostic_information 专门设计用于“全局”catch(...) 块中，以显示有关不应到达的异常的信息。但是，请注意 boost::diagnostic_information 返回的字符串不是用户友好的。

于 2010-01-14T07:34:18.063 回答