使用HttpModule进行异常处理 [英] Exception handling using an HttpModule

问题描述

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

We're reviewing one of the company's system's exception handling and found a couple of interesting things.

大多数代码块（如果不是全部）在一个try / catch块中，在catch块内部，正在抛出一个新的BaseApplicationException - 这似乎是来自Enterprise Libraries。
我在这里有点麻烦，因为我看不到这样做的好处。 （在发生任何时候抛出另一个异常）
一直在使用系统的开发人员之一表示这是因为该类负责发布异常（发送电子邮件和类似的东西），但他不太确定关于它。
在花了一些时间完成代码之后，我很自信地说，这就是收集有关环境的信息，而不是发布它。

Most of the code blocks (if not all of them) are inside a try/catch block, and inside the catch block a new BaseApplicationException is being thrown - which seems to be coming from the Enterprise Libraries. I'm in a bit of a trouble here as I don't see the benefits off doing this. (throwing another exception anytime one occurs) One of the developers who's been using the system for a while said it's because that class's in charge of publishing the exception (sending emails and stuff like that) but he wasn't too sure about it. After spending some time going through the code I'm quite confident to say, that's all it does is collecting information about the environment and than publishing it.

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

My question is: - Is it reasonable to wrap all the code inside try { } catch { } blocks and than throw a new exception? And if it is, why? What's the benefit?

我个人的看法是，使用HttpModule将会更容易，注册Application事件的Error事件，并且做了必要的内部模块。如果我们走下去，我们会想念什么吗？任何缺点？

My personal opinion is that it would be much easier to use an HttpModule, sign up for the Error event of the Application event, and do what's necessary inside the module. If we'd go down this road, would we miss something? Any drawbacks?

您的意见非常感激。

推荐答案

从不 ¹ catch（Exception ex）。期间 ² 。没有办法可以处理您可能会遇到的所有不同类型的错误。

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

从不 ³ 捕获一个Exception导出类型，如果你无法处理或提供附加信息（以供后续异常处理程序使用）。显示错误消息是不与处理相同的错误。

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.

有几个原因，来自我的头顶：

A couple of reasons for this, from the top of my head:

• 收藏和重新投入很贵


• 你最终会失去堆栈跟踪


• 您的代码中的信号与值之间的比率将较低

如果您知道如何处理特定异常（并将应用程序重置为预错误状态），请抓住它。 （这就是为什么它被称为异常 处理 。）

If you know how to handle a specific exception (and reset the application to pre-error state), catch it. (That's why it's called exception handling.)

没有抓住，听取适当的事件。在执行WinForms时，您需要收听 System.AppDomain.CurrentDomain.UnhandledException ，如果您执行线程 - System.Windows.Forms.Application.ThreadException。对于Web应用程序，有类似的机制（ System.Web.HttpApplication.Error throw new MyBaseException（ex））;

To handle exceptions that are not caught, listen for the appropriate events. When doing WinForms, you'll need to listen for System.AppDomain.CurrentDomain.UnhandledException, and - if your doing Threading - System.Windows.Forms.Application.ThreadException. For web apps, there are similar mechanisms (System.Web.HttpApplication.Error).

）：完全无意义，气味不好。 ⁴

编辑

Edit

¹ 苛刻的话，特别是在工程方面，@Chris在评论中指出。当我第一次写这个答案的时候，我承认是很高的原则。

¹ 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 看 ¹

⁴ 如果您没有给桌面带来任何新鲜事物，我仍然坚持这一点。如果您已经捕获异常ex 作为您知道的方法的一部分可能会以多种方式失败，我相信当前的方法应该反映在它的签名中。而且你知道，异常不是方法签名的一部分。

⁴ 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.

这篇关于使用HttpModule进行异常处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！