抓住所有异常的好坏？

Question

我在多个项目中看到一种捕获所有异常以捕获所有意外异常，因此应用程序不会崩溃，我通常会看到：

AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(myUnexpectedExhandler);
Application.ThreadException += new System.Threading.ThreadExceptionEventHandler(threadExHandler);

这是一种好的还是坏的做法。

Answer 1

在项目的顶层捕获异常是正确的。在那里，你可以做一些事情，比如记录它，向你的团队报告细节等等。如果可能的话，应该在某个地方发布例外情况 - 这对开发坚如磐石的产品有很大帮助（参见Jeff Atwood的博客文章“Exception-Driven Development”对此进行了评论。）

什么是不好的做法是在调用堆栈中不正确地捕获异常。你应该捕获异常的唯一时间是你何时知道如何处理它。当然，你永远不应该永远地默默地吞下异常。

Answer 2

总的来说，我会说这完全取决于你，但对我来说这取决于给定项目目前处于什么阶段。在任何项目的初始开发过程中，我更喜欢未捕获的异常来显示一个很好的描述性错误消息它被轰炸的代码行所以我可以解决它。

然而，一旦网站成熟，我使用我构建的自定义ErrorHandler类并将所有错误记录到数据库表中，并且还有每小时（或每日）错误列表e-邮寄给负责该项目的开发人员。需要精细处理的特殊错误通常会在可能破坏的特定代码行周围进行try / catch。

Answer 3

我工作的每个项目最终都会得到一个像这样的全局异常处理程序。

Answer 4

我个人认为完全在生产中依赖是不错的做法。任何可能导致抛出异常的方法或操作都应在该阶段处理（try..catch或传递给custome处理程序类等）。它不仅使应用程序更加健壮，因为您可以以适合该情况的方式处理特定异常，但它也使得更容易找出抛出异常的原因。还有许多日志框架可用于更容易记录异常并处理错误。

我会使用'catch all'异常，但仅作为错误处理的最后一行。

Answer 5

我会说这是一个非常有争议的问题，许多程序员有不同的经历，往往会有不同的意见。我的答案可能有点冗长，但我觉得我不能回答它！

根据我的经验，我相信以下内容：

1. 了解业务需求。 如果它是一个关键应用程序，是的，你是非常的，我们不应该允许应用程序继续，只是通过向用户显示一些适当的消息来让它崩溃。
2. 如果它不是一个非常关键的应用程序，并且您希望用户通过执行其他任务继续使用该应用程序，则允许应用程序正常恢复是有意义的。

要添加上述2点，我还想说，如果在您创建的任何线程中发生未处理的应用程序，则无法恢复任何应用程序。只能恢复主GUI线程上的异常。

添加此类代码的重点是确保调试和错误报告变得简单易行。例如，假设您有一个非常大的应用程序，并且在代码中的某处发生了意外的异常。现在，如果你有像你提到的那样的处理程序，你可以集中整个事情并记录堆栈跟踪，消息等。一旦你有了整个日志，解决问题并知道它的来源就是时间问题。

我希望它有所帮助!!

Answer 6

对于我的观点，在app-level中捕获和记录异常是一种非常好的做法。

但是这绝对不意味着您不必再处理异常，您必须处理您所感知的各个类的异常。

应用程序异常应该仅用于程序不会崩溃和用于日志记录的目的，而不是用作应用程序中的一个大型try-catch。

这又是个人观点。

Answer 7

我经常在制作中使用这样的异常处理程序，我的做法是我可以使用它们：

• 告知用户发生了一些糟糕的DID，但是我确实关心它并会尽快解决它 - 最好这样做而不是显示标准的无聊窗口崩溃对话框
• 使用异常消息，堆栈跟踪和任何其他有趣的信息向我发送电子邮件
• 捕获并从代码中不可避免的已知异常中恢复，并试图以一种不那么灾难性的方式继续前进

HTH

Answer 8

我认为全局异常处理程序将是一件好事。如果您的程序崩溃，那么它允许您使用一个空间来尝试吐出一点数据，这样您就可以找到它崩溃的原因。不建议从全局异常处理程序中恢复，因为可能不知道如何从顶层的任意异常中恢复。

Answer 9

如果您要记录未捕获的异常，请始终使用它记录堆栈跟踪！ 我讨厌得到有日志的bug报告： “未处理的异常” 要么 “未处理的异常：IndexOutOfRangeException”

谢谢，同事们。那很好。