使用IsLine FrameWork開發ASP.NET程式之五—使用ExceptionProcessProvider異常處理架構(上)

    對異常的管理是由IsLine.ExceptionProcess.ExceptionProcessProvider命名空間完成的。

    系統日誌和系統異常是分開記錄的，ILFW將系統日誌與異常分開處理，以提高系統靈活性和安全性。           ExceptionProcessProvider是應用程式需要互動的主要組件，它用來產生異常訊息，產生的異常訊息並不直接顯示，還要預先經過Layout的格式化處理後才會輸出。

    異常模組依附於IsLine.AppLog.AppLogProvider部分，同時異常模組設計時是作為一種特殊的系統日誌來對待的，所以使用Exception模組首先要配置AppLog模組，具體方法參見Aicken的相關文章。

配置好日誌模組後，需要引入上述命名空間，並在web.config中使用“add”標籤添加一個Exception的指標：

    <add key="IsLine.ExceptionProcess.Configuration.RenderName" value="OracleUsingSPRender"/>

    這個指標的作用是告訴Exception模組使用的渲染器，渲染器的名字就是value，模組載入時，會自動載入IsLine.AppLog命名空間下的“渲染器初始化”模組，經過對渲染器的初始化後，才會載入具體的Exception對象。

    這個配置流程說明如下，假使我們需要把異常資訊記入文字檔，後來發現異常很重要，要寫入資料庫予以儲存，那麼我們需要這樣修改web.config檔案。

    1.在<configSections></configSections>之間加入如下節點sectionGroup name為“FileRender “與”OracleUsingSPRender “的節點

    2.在</configSections><appSettings>之間加入對應Render的配置內容。

    3.使用

<add key="IsLine.ExceptionProcess.Configuration.RenderName" value="OracleUsingSPRender"/>指明異常使用的日誌模型。“OracleUsingSPRender”是我們在第2步指明的兩個日誌模型其中一個的名字，現在系統中所有異常資訊都會按照“OracleUsingSPRender”模型所描述的介質寫入了。

   這時老闆突然出現說，異常不用記Oralce了，記錄文字檔就可以了，好吧，我們只需改一下異常渲染器的名字就可以，將“OracleUsingSPRender”改為“FileRender”，這樣系統中的異常就會自動轉向文字檔了。文字檔的路徑在“AppenderInf”標籤中描述，記錄內容在“AppenderContent”標籤中描述。

上述過程的配置代碼請參考作者的部落格。

系統異常記錄

    該命名空間負責記錄系統中的異常資訊，程式人員可以直接將.Net中的“Exception”對象直接拋送給ExceptionProcessProvider，該Provider自動將Exception類型轉換為剛才提到的“LogEntity”，並寫入相應的介質，對應介質以及其他資訊與日誌節點可以相同，亦可以使用單獨節點，互不影響。

    另一種標準的ExceptionProcessProvider使用方式是值得推薦的，在上文中提到，系統設計時，一般本人會預先建立業務實體模型、業務事件模型、業務訊息模型，在業務實體模型中，包括業務模型和異常模型。其中異常模型的設計是在系統設計階段完成的，它預先定義了系統運行時可能會發生的錯誤，並為這些錯誤建立模型。

    每一種自訂的異常模型須繼承ExceptionEntity基類，並實現IexceptionProcess介面，這樣做不但量化了系統異常，有效管理了系統中的異常，而且增強了系統安全性。在上層調用異常模組時，也無須顯示使用WriteLog()方法，當Catch捕獲到系統異常後，ExceptionProcessProvider會自動攔截，並將進入ILFW異常模組的處理流程。

    IsLine FrameWork 目前支援兩種異常記錄模式：

1. 使用ILException類記錄異常

這種方式是最簡單的方式，在對web.config進行簡單的資訊配置後，可以在程式中直接截獲並記錄異常，但缺點是需要對各種異常進行遍曆。這種方式代碼如下：

            try
           {
               string i = "i";
               Response.Write(i);
           }
           catch (Exception ex)
           {
               ILException ile = new ILException();
               ile.WriteLog(ex);
           }

   2.使用自訂異常記錄異常資訊

    自訂異常記錄的方式是比較標準的OOP原則方式，你需要在系統設計階段量化每一種異常，並且為這些異常建模，所有模型類必須繼承ILException類，並且實現WriteLog()方法

    關於WriteLog()方法的實現，可以在異常類內部直接調用ILException的WriteLog(ex)實現，這是很簡單的事情。

然後你就可以通過以下代碼使用這個異常管理模組了：

            try
             {
                 string i = "i";
                 Response.Write(i);
             }
             catch (ILException ex)
             {
                 ex.WriteLog(ex);
             }

    由於事先對異常進行了定義，系統不必再遍曆Exception樹，所以這種方法擁有較高的效能，並且體現了抽象與封裝的原則。

    系統異常模組除了記錄功能，還有一個很重要的功能：異常展示，即系統發生異常後，展示給使用者怎樣的頁面。展示給方便使用頁面具有以下必要性：

    ● 展示給方便使用頁面，可以降低使用者焦慮感，提高使用者體驗。

    ● 將系統異常隱藏，避免代碼、路徑等技術資訊外泄，提高系統安全性。

    ● 將系統運行時異常統一管理，有助於提高軟體整體品質，便於整體把控。

    友好頁面的展示類型也是根據配置節點資訊完成的，管理員只需更改配置節點中的枚舉值，即可改變使用者體驗頁面，使用者體驗頁面共有10中方式，分別是拋出原始異常資訊、拋出定製異常資訊、拋出簡單資訊(不包含異常)以及隱藏異常資訊等方式。

    在系統開發階段，可以使用拋出原始異常資訊的展現方式，系統部署後，可以使用拋出簡單資訊(不包含異常)或隱藏異常資訊的方式，選擇這些展示方式的同時，還可以選擇是否記錄到日誌介質。

    該異常模組完美的提供裡以上功能，使用者可以自由選擇是否將特定內容記錄到日誌中，並確定記錄介質；同時使用者可以選擇系統發生異常後，將以何種方式展現給使用者。IsLine FrameWork為系統開發人員提供了多種異常記錄方式，這些方式可以同時存在，只要你有這個需要，即你可以將不同業務的異常記錄至不同的介質中；並且它還為系統提供了統一的異常展示方式，系統的異常將以一個統一的面貌返回給使用者。異常記錄與展示甚至是軟體工程的系統需求分析階段可以確定的，這將更有利於監控系統的運行。

此文已在《軟體報》同步發布，任何個人媒體不得轉載。