我们正在审查公司的一个系统的异常处理，并发现了一些有趣的事情。
大多数代码块(如果不是全部)都在 try/catch block 内，并且在 catch block 内抛出一个新的 BaseApplicationException - 这似乎来自企业库。 我在这里有点麻烦，因为我看不到这样做的好处。 (任何时候抛出另一个异常) 一位使用该系统一段时间的开发人员说，这是因为该类负责发布异常(发送电子邮件和类似的东西)，但他对此不太确定。 在花了一些时间查看代码后，我非常有信心地说，它所做的只是收集有关环境的信息，而不是发布它。
我的问题是: - 将所有代码包装在 try { } catch { } block 中并抛出新异常是否合理？如果是，为什么？有什么好处？
我个人的看法是，使用 HttpModule 会容易得多，注册 Application 事件的 Error 事件，并在模块内部执行必要的操作。如果我们沿着这条路走下去，我们会错过什么吗？有什么缺点吗？
非常感谢您的意见。
最佳答案
从不1 捕获(异常ex)。期间2。您无法处理可能捕获的所有不同类型的错误。
永远不要3 如果您不能处理异常派生类型或无法提供额外信息(供后续异常处理程序使用)，则不要捕获它。显示错误消息与处理错误不同。
这有几个原因，从我的头顶来看:
- 捕获和重新抛出是昂贵的
- 你最终会丢失堆栈跟踪
- 您的代码中的信噪比较低
如果您知道如何处理特定 异常(并将应用程序重置为错误前的状态)，请捕获它。 (这就是为什么它被称为异常处理。)
要处理未捕获的异常，请监听适当的事件。在执行 WinForms 时，您需要监听 System.AppDomain.CurrentDomain.UnhandledException，并且 - 如果您执行 Threading - System.Windows.Forms.Application .ThreadException. 对于网络应用程序，有类似的机制(System.Web.HttpApplication.Error)。
至于在您的应用程序(非)特定异常中包装框架异常(即 throw new MyBaseException(ex);):完全没有意义，而且有难闻的气味。4
编辑
1 从不 是一个非常苛刻的词，尤其是在涉及工程时，正如@Chris 在评论中指出的那样。当我第一次写这个答案时，我会承认我的原则很高。
2,3 参见1。
4 如果您没有带来任何新的东西，我仍然坚持这一点。如果您将 Exception ex 作为您知道可能以多种方式失败的方法的一部分捕获，我相信当前方法应该在其签名中反射(reflect)出来。如您所知，异常不是方法签名的一部分。
关于c# - 使用 HttpModule 进行异常处理，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/132607/