异常处理—Exception(三)

最近有点事,把这个系列给落下了,给你们道个歉,这里还要感谢个人老婆,谢谢她一直对个人支持:)html

系列回顾:web

1异常处理--Exception(一)数据库

2异常处理—Exception(二)安全

上一篇中主要介绍了Log的几种方式,接下来讲说通知的方式:服务器

通知方式架构

说明app

Emailpost

这是最多见也是最方便的一种通知方式。网站

优势:使用简单url

缺点:须要依赖于SMTP服务器等

SMS

这也是目前比较流行的通知方式,不过通常不会把全部信息都经过短信进行发送,能够选几个比较关键的Exception进行SMS通知。

缺点:字数、网关、接口等限制。

优势:及时性

Post

经过某种服务,对客户端进行Post Exception

优势:及时性(不过依赖于客户端)

缺点:须要编写安全的客户端程序。

Get

Post优势相似,但须要把Exception先存到某个地方,而后Get的时候获取。

Other

还有不少通知的方式,这个取决于你们的需求了。

 

通常咱们经常使用的是前2种方式,由于编写还算简单,SMS的接口如今也有不少了。

注:若是在你的程序种有Email发送程序的话,我建议您仍是不要使用相同的配置进行发送,建议从新创建一个新的配置,包括发送方式都使用一个新的方法

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

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

通知的内容不是不少,下面来讨论一下 Try / Catch

这个问题原本先前就想说的,前几天也看到杨兄弟的“请讨论try...catch..写在不一样地方,有何利害? ”其中讨论的很是激励,不少人说的都比较正确,使我以为或许个人方案不是最好的,但我决定仍是把个人见解写出来,这样才能你们一块儿来进行讨论。老赵说在内部类的时候最好也能把异常捕捉后,进行封装而后再抛出,不过我我的以为,若是是类库的话,仍是不要去Catch,这是为何呢?

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

如今说说个人观点,通常咱们的网站会使用三层架构,不过为了解除业务逻辑与页面层的耦合,咱们会借助某些模式,以下降它的耦合度。(本身的想法,或许某些概念会错误)

咱们的网站大可能是对数据库的IUDS的操做,因此数据层基本已经属于了底层类库,业务层进行调用,UI层进行显示信息。(那咱们是否是对数据层的异常不进行处理呢?也不必定,若是按照我先前说的,最好是不要在底层进行处理,没有错,但咱们不能太绝对,仍是根据你的项目来分析后进行安排吧。)

有人会说在数据层,咱们会使用ADO等方法,会与数据库进行必定的联系,其中就会抛出各类异常,难道咱们不要去处理吗?是的,若是可能,请不要在这里进行处理,个人方案是,去业务层进行捕捉和处理。

业务层咱们是否是去把全部异常都处理了呢?请不要这样设想,由于有些异常不是你能所有处理的,咱们应该把咱们能预知的,咱们须要的异常进行处理(姑且把咱们的处理程序定义为ExceptionManager)丢到ExceptionManager中进行处理。但咱们有时须要抛出一些Exception Message给用户,因此这些异常,请封装好,继续往高层Throw,这时,请不要把异常丢到ExceptionManager,由于后面咱们会有其余地方进行处理的。

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

其实很简单,使用一个HttpModule就能够了,在这个Module中不要牵涉到其余任何东西,由于在Asp.Net中,一个请求的顺序会把你全部的Module都会执行一次,因此没必要担忧.Net会遗漏,咱们只须要配置好就能够了。那咱们这个Module只要作哪些工做呢?只须要处理未处理的异常,首先看一段代码:

 

ExceptionHandlingModule

 1public class ExceptionHandlingModule : IHttpModule
   {
       IHttpModule 成员#region IHttpModule 成员

       public void Dispose()
       {

       }

       public void Init(HttpApplication context)
       {
           context.Error += new EventHandler(context_Error);
       }

       void context_Error(object sender, EventArgs e)
       {
           var application = (HttpApplication)sender;

           //获取当前请求的前一个错误
           //这里的GetLastError 实际上是一个封装好的Exception
           //咱们若是想要知道真正的Exception的话,须要用InnerException属性获取。
           var unHandlingException = application.Context.Server.GetLastError();
           if (unHandlingException != null)
           {
               unHandlingException = unHandlingException.InnerException;
               if (unHandlingException != null)
               {
                   ExceptionManager.HandlingException(unHandlingException);

                   //好了,咱们已经把unHandlingException处理了,后面就清除吧
                   application.Context.ClearError();

                   //固然,若是你想要用户看到错误提示信息的话,记得把Message保留下来
               }
           }
       }

       #endregion
   }

 

 

第三篇就说到这里吧,接下来后面将会把自定义异常、处理的代码给你们说明一下。

其实不少内容都是通过修改了,原先的想法在我写博客的时候,感受愈来愈不对劲,看来我还得加把劲,有些地方或许说的不是很合理,也但愿你们能给我提出建议,以避免误导其余读者:)

 

出处:http://www.cnblogs.com/inday/archive/2009/05/06/1451041.html

相关文章
相关标签/搜索