捕获所有异常好还是坏？答案

【问题标题】：Catch all exception good or bad?捕获所有异常好还是坏？
【发布时间】：2025-12-04 16:20:16
【问题描述】：

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

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

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

【问题讨论】：

forums.thedailywtf.com/forums/p/8499/161670.aspx（对不起，我不得不这样做。）
大声笑，这是一个很好的大声笑

标签： .net exception-handling

【解决方案1】：

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

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

【讨论】：

+1 The only time you should catch an exception is when you know exactly what to do with it.
但是如果在尝试记录异常时发生异常，您不应该吞下异常，这样您就不会陷入循环吗？
在这种情况下，它将属于“您确切知道如何处理它”类别 - 可能值得考虑某种后备记录器，但除此之外，如果您的异常记录本身失败了，你无能为力。

【解决方案2】：

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

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

【讨论】：

【解决方案3】：

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

【讨论】：

【解决方案4】：

我个人认为在生产中完全依赖它不是一个好习惯。任何可能导致抛出异常的方法或动作都应在该阶段处理（try..catch 或传递给客户处理程序类等）。它不仅使应用程序更加健壮，因为您可以以适合情况的方式处理特定的异常，而且还可以更容易地找出抛出异常的原因。还有许多日志框架可供使用，可以更轻松地记录异常和处理错误。

我会使用“捕获所有”异常，但仅作为错误处理的最后一行。

【讨论】：

【解决方案5】：

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

根据我的经验，我相信以下几点：

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

为了补充以上两点，我还想说，如果在您创建的任何线程中出现未处理的应用程序，您将无法恢复任何应用程序。只能恢复主 GUI 线程上的异常。

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

希望对你有帮助！

【讨论】：

【解决方案6】：

在我看来，在应用程序级别捕获和记录异常是一种非常好的做法。

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

应用程序异常应仅用于程序不崩溃和用于记录目的，而不应用作应用程序中的一大尝试。

这也是个人意见。

【讨论】：

【解决方案7】：

我经常在生产中使用此类异常处理程序，我的做法是我可以使用它们来：

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

HTH

【讨论】：

【解决方案8】：

我认为全局异常处理程序将是一件好事。如果您的程序崩溃，那么它允许您尝试吐出更多的数据位，这样您就有希望找出它崩溃的原因。不建议从全局异常处理程序中恢复，因为您可能不知道如何从顶层的任意异常中恢复。

【讨论】：

【解决方案9】：

如果您要记录未捕获的异常，请始终使用它记录堆栈跟踪！我讨厌收到具有以下日志的错误报告： “未处理的异常” 或者 “未处理的异常：IndexOutOfRangeException”

谢谢各位同事。太好了。

【讨论】：