使用HttpModule进行异常处理

我们正在审查该公司系统的异常处理之一,并发现了一些有趣的事情.

大多数代码块(如果不是全部)都在try/catch块中,并且在catch块内部抛出新的BaseApplicationException - 这似乎来自企业库.我在这里遇到了一些麻烦,因为我没有看到这样做的好处.(在任何时候发生另一个例外)其中一个开发人员一直在使用该系统说这是因为该类负责发布异常(发送电子邮件和类似的东西),但他不太确定.在花了一些时间浏览代码之后,我非常有信心地说,这就是收集有关环境的信息而不是发布它.

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

我的个人意见是,使用HttpModule会更容易,注册Application事件的Error事件,并在模块内部执行必要的操作.如果我们走这条路,我们会错过什么吗？有什么缺点吗？

您的意见非常感谢.

1> Christoffer ..：

---

从来没有¹ catch (Exception ex).期间².您无法处理可能遇到的所有不同类型的错误.

从未³捕捉异常衍生的类型,如果你不能处理它或提供额外的信息(由随后的异常处理程序中使用).显示错误消息是不一样处理该错误.

有几个原因,从我的头脑中:

捕捉和重新抛弃是昂贵的

你最终会失去堆栈跟踪

您的代码中的信号与噪声比率较低

如果您知道如何处理特定异常(并将应用程序重置为错误前状态),请捕获它.(这就是为什么它被称为异常 处理.)

要处理未捕获的异常,请侦听相应的事件.在做WinForms时,你需要监听System.AppDomain.CurrentDomain.UnhandledException,并且 - 如果你正在做Threading- System.Windows.Forms.Application.ThreadException.对于网络应用程序,有类似的机制(System.Web.HttpApplication.Error).

至于在您的应用程序中包装框架异常(非)特定异常(即throw new MyBaseException(ex);):完全没有意义,并且有难闻的气味.⁴

---

编辑

¹ @Chris在评论中指出,从来都不是一个非常严厉的词,特别是在工程方面.当我第一次写这个答案时,我会承认自己的原则很高.

^2,3见¹.

⁴如果你没有带来任何新的东西,我仍然坚持这一点.如果你已经抓住Exception ex了一个你知道可能以多种方式失败的方法的一部分,我相信当前的方法应该反映出它的签名.如您所知,异常不是方法签名的一部分.

---

-1使用从不.永远和永远在工程中的话几乎总是错误的.`catch(Exception ex)`有许多有效的案例,主要与使用外部资源有关,无论是磁盘,服务器还是网址.当外部依赖性出现故障时,可以生成各种疯狂的异常以尝试处理每个异常是徒劳的,通常只是统一处理对资源的任何失败访问,或者统一失败.当包含诸如`throw new DatabaseOfflineException(innerException)`之类的异常变得完全可以接受时,这也会进入.