一个让人遗忘的角落—Exception（三）

最近有点事，把这个系列给落下了，给大家道个歉，这里还要感谢我的老婆，谢谢她一直对我的支持：）

系列回顾：

1．一个被人遗忘的角落—Exception（一）
2．一个被人遗忘的角落—Exception（二）

上一篇中主要介绍了Log的几种方式，接下来说说通知的方式：

通知方式	说明
Email	这是最常见也是最方便的一种通知方式。优点：使用简单缺点：需要依赖于SMTP服务器等
SMS	这也是目前比较流行的通知方式，不过一般不会把所有信息都通过短信进行发送，可以选几个比较关键的Exception进行SMS通知。缺点：字数、网关、接口等限制。优点：及时性
Post	通过某种服务，对客户端进行Post Exception。优点：及时性（不过依赖于客户端）缺点：需要编写安全的客户端程序。
Get	跟Post优点类似，但需要把Exception先存到某个地方，然后Get的时候获取。
Other	还有很多通知的方式，这个取决于大家的需求了。

一般我们常用的是前2种方式，因为编写还算简单，SMS的接口现在也有很多了。

注：如果在你的程序种有Email发送程序的话，我建议您还是不要使用相同的配置进行发送，建议重新建立一个新的配置，包括发送方式都使用一个新的方法。

这里值得注意的是，当你的Email通知方式抛出异常时，请一定要使用另外一种方式进行通知，因为此时可能你的网站已经发生了不可忽视的异常了。

通知的信息内容比较简单，如果是Email发送方式，就可以使用Log的Log信息进行发送，如果SMS的话，你可以使用模板，或者固定格式进行发送。

通知的内容不是很多，下面来讨论一下 Try / Catch

这个问题本来先前就想说的，前几天也看到杨兄弟的“请讨论try...catch..写在不同地方,有何利害? ”其中讨论的非常激励，很多人说的都比较正确，使我觉得或许我的方案不是最好的，但我决定还是把我的看法写出来，这样才能大家一起来进行讨论。老赵说在内部类的时候最好也能把异常捕捉后，进行封装然后再抛出，不过我个人觉得，如果是类库的话，还是不要去Catch，这是为什么呢？

我认为，类库中的方法是我们程序的最小单元，它的存在是为了我们高层的调用，它的存在必有它的意义，就算它内部调用其他类库的方法（大多会调用FCL），我们最好不要去Catch掉，不过某些时候你可能要违反这个规则，但请记住，封装好你的异常，然后Throw到高层，那样才能不遗漏你的程序发生的Exception。类库中的方法，如果会调用很多其他类库的方法时，你应该考虑你的这个类库或许已经存在了几种可能性改变你的结果了，你该好好的重新设计你的方法。

现在说说我的观点，一般我们的网站会使用三层架构，不过为了解除业务逻辑与页面层的耦合，我们会借助某些模式，以降低它的耦合度。（自己的想法，或许某些概念会错误）

我们的网站大多是对数据库的I、U、D、S的操作，所以数据层基本已经属于了底层类库，业务层进行调用，UI层进行显示信息。（那我们是不是对数据层的异常不进行处理呢？也不一定，如果按照我先前说的，最好是不要在底层进行处理，没有错，但我们不能太绝对，还是根据你的项目来分析后进行安排吧。）

有人会说在数据层，我们会使用ADO等方法，会与数据库进行一定的联系，其中就会抛出各种异常，难道我们不要去处理吗？是的，如果可能，请不要在这里进行处理，我的方案是，去业务层进行捕捉和处理。

业务层我们是不是去把所有异常都处理了呢？请不要这样设想，因为有些异常不是你能全部处理的，我们应该把我们能预知的，我们需要的异常进行处理（姑且把我们的处理程序定义为ExceptionManager）丢到ExceptionManager中进行处理。但我们有时需要抛出一些Exception Message给用户，所以这些异常，请封装好，继续往高层Throw，这时，请不要把异常丢到ExceptionManager中，因为后面我们会有其他地方进行处理的。

到此，轮到我们的UI层了，UI层直接面对的是用户，在我们先前说的，我们必须记录下我们的异常，让后给用户呈现一个友好的用户界面，那样才是做网站的王道。在web.config中，可以设置发生错误时所呈现的一个页面Url，虽然这么做可以给用户一个好的友好界面，但有时，我们需要给用户提供更多的信息，比如请输入用户名等，这时候config配置的页面就无法达到我们的要求了，那我们该如何来做呢？

其实很简单，使用一个HttpModule就可以了，在这个Module中不要牵涉到其他任何东西，因为在Asp.Net中，一个请求的顺序会把你所有的Module都会执行一次，所以不必担心.Net会遗漏，我们只需要配置好就可以了。那我们这个Module只要做哪些工作呢？只需要处理未处理的异常，首先看一段代码：