异常记录器：最佳实践

Question

我刚开始在我的（Delphi）应用程序中使用异常记录器（EurekaLog）。现在，我的应用程序每天都会通过电子邮件向我发送大量错误消息。这里是我发现了迄今为止

• 大量重复的错误，从相同的PC

多个邮件虽然这是非常宝贵的投入，以提高我的申请，我稍微纯粹不堪重负我得到的信息量。

从您的应用程序处理邮件的最佳做法是什么？

Answer 1

我认为你应该丢弃所有重复。只留下报告的数量。即如果有100个报告，但只有4个独特的问题 - 只留下4个报告，丢弃其他96个报告，但使用他们的计数按严重程度对报告进行分类。例如，第6个问题报告6个，第3个10个报告，第2个20个，第1个60个。所以，你应该修复60个报告的第一个问题，然后切换到第二个。

我相信EurekaLog在其报告中有BugID。相同的问题具有相同的BugID。这将允许您对重复的报告进行分类。 EurekaLog Viewer还可以整理重复。

Answer 2

如果你得到很多信息，因为它是目前的情况下，你根本得不到任何信息。

所以我会说你的错误分为组，如警告，致命错误等 然后限制你的电子邮件到最重要的信息（致命）。 除此之外，定期检查您的日志（日，周...）。

Answer 3

这很大程度上取决于发回的错误。显而易见的是，如果您的应用程序出现错误，他们需要修复并发送给客户端的修补程序/更新。

如果它们是您知道可能发生的异常，并且不需要通知您，则可以在Eureaka Log选项中添加“Exception Filters”以指定应如何处理（或忽略！）。

另一种选择是在邮件主题行中使用EurekaLog变量（您可以在其中添加例外描述等），然后使用您的电子邮件客户端进行基于此的过滤。

Answer 4

我使用madExcept作为核心，但我自己的传输机制，我的异常日志记录所做的是让他们都进入数据库。核心信息全部从每个报告中提取出来并放入字段中，并且整个报告也存储起来。堆栈跟踪会自动分析以删除不感兴趣的功能，仅留下我失败的功能列表。由于这种情况会自动发生，我现在可以“忽略”每个单独的消息进来，但在一个网格中看到更大的图像，它显示了哪些功能最具问题。然后，我可以专注于它们，寻找原因并修复它们。

如果我选择，我的显示应用程序也可以在构建之前筛选出构建中的报告，这样我就可以告诉它在构建75之前不要包含“MyWidget.BadProc”。

这帮助我改进了我的应用程序，解决了人们发现问题最多的问题，而无需猜测。

Answer 5

我用madExcept做了这个。这对于追踪我们无法再现的问题非常有用。

这让我问你为什么这么多？未经处理的例外应该是少之又少。特别是如果用户看到错误对话框。我负责几个应用程序，每个应用程序都有数百次安装，我很少会收到电子邮件通知。

如果他们主要来自少数几台PC，我会与这些用户中的一些人一起找出他们做了什么不同的事情，或者他们的设置如何产生异常。

如果他们来自各地，这可能是一个错误，通过您的测试。

无论哪种方式，使用细节来修复你的代码，或者，至少，预测已知的异常，并适当地捕获它们（没有空的try..except）。

解决热点问题会减少您获得的电子邮件的数量，使偶尔的通知变得更易于管理。