使用 HttpModule 进行异常处理

我们正在审查该公司的一个系统的异常处理，发现了一些有趣的事情。

大多数代码块（如果不是全部）都位于 try/catch 块内，并且在 catch 块内抛出一个新的 BaseApplicationException - 这似乎来自企业库。 我在这里遇到了一些麻烦，因为我看不到这样做的好处。 （每当发生异常时抛出另一个异常） 一位已经使用该系统一段时间的开发人员表示，这是因为该类负责发布异常（发送电子邮件之类的东西），但他对此不太确定。 在花了一些时间浏览代码后，我非常有信心地说，它所做的只是收集有关环境的信息，而不是发布它。

我的问题是： - 将所有代码包装在 try { } catch { } 块中而不是抛出新的异常是否合理？如果是的话，为什么？有什么好处？

我个人的观点是，使用 HttpModule、注册 Application 事件的 Error 事件并在模块内执行必要的操作会更容易。如果我们沿着这条路走下去，我们会错过什么吗？有什么缺点吗？

非常感谢您的意见。

Never¹ catch (Exception ex). Period². There is no way you can handle all the different kinds of errors that you may catch.

Never³ catch an Exception-derived type if you can't handle it or provide additional information (to be used by subsequent exception handlers). Displaying an error message is not the same as handling the error.

从我的角度来看，有几个原因：

• 捕捉和重新抛出的成本很高
• 你最终会丢失堆栈跟踪
• 您的代码中的信噪比较低

如果你知道如何处理specific异常（并将应用程序重置到错误前状态），捕获它。 （这就是为什么它被称为例外 handling.)

要处理未捕获的异常，请侦听适当的事件。在执行 WinForms 时，您需要监听System.AppDomain.CurrentDomain.UnhandledException，并且 - 如果你这样做Threading - System.Windows.Forms.Application.ThreadException.对于网络应用程序，也有类似的机制（System.Web.HttpApplication.Error).

As for wrapping framework exceptions in your application (non-)specific exceptions (i.e. throw new MyBaseException(ex);): Utterly pointless, and a bad smell.⁴

Edit

¹ Never is a very harsh word, especially when it comes to engineering, as @Chris pointed out in the comments. I'll admit to being high on principles when I first wrote this answer.

^2,3 See ¹.

⁴ If you don't bring anything new to the table, I still stand by this. If you have caught Exception ex as part of a method that you know could fail in any number of ways, I believe that the current method should reflect that in it's signature. And as you know, exceptions is not part of the method signature.