基於AOP的MVC攔截異常讓代碼更優美

與asp.net 打交道很多年，如今天微軟的優秀框架越來越多，其中微軟在基於mvc的思想架構，也推出了自己的一套asp.net mvc 框架，如果你親身體驗過它，會情不自禁的說‘漂亮’。回過頭來，‘漂亮’終歸有個好的思想，其中類似於AOP的思想，就在其中體現的淋漓盡致，今天本文主要討論的是基於AOP ...

與asp.net 打交道很多年，如今天微軟的優秀框架越來越多，其中微軟在基於mvc的思想架構，也推出了自己的一套asp.net mvc 框架，如果你親身體驗過它，會情不自禁的說‘漂亮’。回過頭來，‘漂亮’終歸有個好的思想，其中類似於AOP的思想，就在其中體現的淋漓盡致，今天本文主要討論的是基於AOP思想構成的‘異常過濾器’。我們的目的只有一個，讓try...catch...無處盾形，讓代碼更健壯優美。

一、理解mvc里filter是怎麼運行的

老外的一篇文章是這樣的草圖

通過翻譯中文是這樣的

其中有一個異常過濾器

通過上述的表格可以清楚的看出，當Controller或Action執行時，IExceptionFiter的實現基類都將有‘能力’處理的，其中微軟在mvc中預設實現了一個實現類HandleErrorAttribute

看看這個的源碼是怎麼能出的

public virtual void OnException(ExceptionContext filterContext)
        {
            if (filterContext == null)
            {
                throw new ArgumentNullException("filterContext");
            }
            if (!filterContext.IsChildAction && (!filterContext.ExceptionHandled && filterContext.HttpContext.IsCustomErrorEnabled))
            {
                Exception innerException = filterContext.Exception;
                if ((new HttpException(null, innerException).GetHttpCode() == 500) && this.ExceptionType.IsInstanceOfType(innerException))
                {
                    string controllerName = (string) filterContext.RouteData.Values["controller"];
                    string actionName = (string) filterContext.RouteData.Values["action"];
                    HandleErrorInfo model = new HandleErrorInfo(filterContext.Exception, controllerName, actionName);
                    ViewResult result = new ViewResult {
                        ViewName = this.View,
                        MasterName = this.Master,
                        ViewData = new ViewDataDictionary<HandleErrorInfo>(model),
                        TempData = filterContext.Controller.TempData
                    };
                    filterContext.Result = result;
                    filterContext.ExceptionHandled = true;
                    filterContext.HttpContext.Response.Clear();
                    filterContext.HttpContext.Response.StatusCode = 500;
                    filterContext.HttpContext.Response.TrySkipIisCustomErrors = true;
                }
            }
        }

這些代碼的思路是這樣的

HandleErrorAttribute-->HandleErrorInfo(model)-->ViewResult-->{ViewName:Error}

即拋出一個Share文件夾里的Error視圖。

可以看出以Filter形式給出的，說明它有能力以特性的形式‘貼’在控制器Controller或Action上，讓代碼更為‘優美’！因為Filter微軟也給我們留了‘FilterConfig’入口，可以全局性的‘註入’

至此，我們可以看出，有至少有兩種形式來規劃的我的‘異常’，一是以特性的形式‘貼’在Controller和Action上，二是，以全局的‘FilterConfig’註冊。不管怎麼樣，結果只有一個，try...catch...離我們漸漸遠去了，不是嗎？那我們繼續看下去！

異常通過以'里'向'外'拋出去的，就像我們常常看到的異常黃頁，那個是拋到最外面的一個異常頁面。

1.Action-->HandleErrorAttribute（預設）-->IExceptionFilter-->OnException

2.Controller-->HandleErrorAttribute（預設）-->IExceptionFilter-->OnException

二、自定義我們的異常類

在自定義我們的異常輔助類前，我們首先明確的幾點：

1.全局的異常用CustomExceptionAttribute自定義異常類來捕獲。

2.對於Action是JsonResult的用Json格式的‘事件’用‘AsyncExceptionAttribute’異常來捕獲。

順序是：Action-->AsyncExceptionAttribute-->CustomExceptionAttribute-->HandleErrorAttribute（預設）-->IExceptionFilter-->OnException

在Action里發生異常，如果是JsonResult，用AsyncExceptionAttribute來捕獲出去，然後進行全局的CustomExceptionAttribute

當設定 filterContext.ExceptionHandled=True時表示此異常’已被處理‘，反之異常在後續的捕獲機制中向外拋出，這個由自己的需要自由訂製。

1）AsyncExceptionAttribute定義：

如果是JsonResult異常的話，我們進行處理組合成一個Data,狀態為success=false,message='異常信息'。

這裡沒有做filterContext.ExceptionHandled=True處理，為了讓異常向’外拋‘CustomExceptionAttribute 處理，因為我們要記錄這個異常日誌，而不是僅僅的顯示給UI界面。

2）CustomExceptionAttribute全局異常：

 public override void OnException(ExceptionContext filterContext)
        {

            int StatusCode = filterContext.HttpContext.Response.StatusCode;

            if (filterContext.Exception != null && StatusCode != 404)
            {

                //寫入日誌 記錄
                string message = string.Format("------------------------------------------------------------------------------------------------------------------------------------------------------------\r\n下麵是捕獲的異常信息摘要：\r\n 時間：{0}\r\n消息類型：{1}\r\n 消息內容：{2}\r\n 引發異常的方法：{3}\r\n 引發異常源：{4}"
                     , DateTime.Now
                     , filterContext.Exception.GetType().Name
                     , filterContext.Exception.Message
                     , filterContext.Exception.TargetSite
                     , filterContext.Exception.Source + filterContext.Exception.StackTrace
                     );

                DbEntityValidationException e = filterContext.Exception as DbEntityValidationException;

                if (e != null && e.EntityValidationErrors.Count() > 0)
                {
                    System.Text.StringBuilder tempDate = new StringBuilder("\r\n下麵是捕獲的驗證類詳細信息:\r\n");

                    foreach (var eve in e.EntityValidationErrors)
                    {
                        tempDate.AppendLine(string.Format("Entity of type \"{0}\" in state \"{1}\" has the following validation errors:",
           eve.Entry.GetType().Name, eve.Entry.State));

                        foreach (var ve in eve.ValidationErrors)
                        {
                            tempDate.AppendLine(string.Format("- Property: \"{0}\", Error: \"{1}\"",
                                ve.PropertyName, ve.ErrorMessage));
                        }
                    }

                    message += tempDate.Append("\r\n").ToString();
                }

                Task t = new Task(() =>
                {
                    WL.Common.SysLogHelp.WriteLogFile("ErrorLog", message, filterContext.HttpContext);
                });

                t.Start();
                //t.Wait();
            }

            if (filterContext.Result is JsonResult)
                filterContext.ExceptionHandled = true;
            else
                base.OnException(filterContext);

        }

CustomExceptionAttribute全局異常定交方法，首先排除不是404的異常，因為，404可能是死鏈，網站不應該處理，交給IIS級的異常程程式處理。

IIS配置管理員（windows 2012）

IIS 配置管理器里有兩個’錯誤‘處理機制，在.NET配選項里配置404頁，有個一潛在的問題StatusCode=304而不是404,微軟也有相關的說明，而在IIS錯誤頁里配置的話沒有問題！

//在此節里配置不會得到正確的404 StateCode
</customErrors>

提倡的應該在 HttpErrors節點配置

<httpErrors errorMode="Custom" existingResponse="Replace">
<clear/>
<error statusCode="404" path="ErrorPages\404.html"/>
<error statusCode="500" path="ErrorPages\500.html"/>
</httpErrors>

再看看列印出的404頁面狀態碼

這次就正確了，所以404頁要交給IIS處理，我們上述代碼沒有處理404頁，如果處理的話，那麼可能得不到StatusCode=404的狀態碼，錶面上UI沒有任何問題，但對於SEO而言，死鏈得不到及時處理。

話題轉回來，繼續我們的文章。

同時上面的代碼對於filterContext.Result is JsonResult 設置filterContext.ExceptionHandled = true，而對於其它的異常base.OnException(filterContext)，繼續向外面處理，防止有其它異常不能及時處理。我們用了Task任務非同步來寫入日誌，寫日誌畢竟也是浪費時間的嘛。

現在我們測試下，這兩種異常吧，看看代碼是不是’優美‘了許多

前臺Test Code: