在上一篇教學中我為大家介紹了Web API中Filter的開發使用，其中講到ExceptionFilter時留了一個坑：ExceptionFilter只能截獲並處理Action執行過程中發生的異常，在Action執行過程之外如果出現異常，ExceptionFilter是無能為力的。
這些例外包括：
1、 Controller建構法中出現的例外狀況
2、 MessageHandlers中出現的例外狀況
2、 MessageHandlers中出現的例外狀況
3、 出現在路由過程中出現的異常
4、 Body在序列化/反序列化過程中出現的異常
由此可以看出，ExceptionFilter只能解決ApiControler成功實例化後並執行Action期間出現的例外；為了解決這一個問題，在WEB API中除了ExceptionFilter外還引入了兩個針對異常記錄、處理的擴充點：
IExceptionLogger 和IExceptionHandler。
而這兩個擴充功能是作為Web API的管道元件進行註冊管理的，並且，他們有不同的分工：
IExceptionLogger作為異常日誌記錄，負責 IExceptionLogger作為異常記錄記錄，他貫穿整個Web API的生命週期中，在Web API框架裡，任何一個請求週期中出現任何一個未被捕獲/處理的異常都會首先進入這個異常日誌記錄管道進行異常Log記錄，在Web API中可以註冊多個IExceptionLogger實例負責不同的異常處理。
IExceptionHandler作為異常處理元件，負責異常發生後的處理工作，他處於異常處理管道的最末端，當IExceptionLogger元件進行一場記錄完畢、沒有相關的ExceptoinFilter進行異常處理時，才會最終最終呼叫ExceptionHandler進行異常處理，在Web API中，有且僅有一個ExceptionHandler進行異常的處理。
在Web API架構中給出了兩個基底類別：ExceptionLogger和ExceptionHandler，在使用ExceptionLogger基底類別時，他提供了ShouldLog虛方法，該方法在基底類別中被調用，其作用在於避免同一個異常被同一個ExceptionLogger實例重複記錄（如當後續的管道中該異常又被拋出，或者同一個ExceptionLogger物件不小心被註冊了兩次就會出現重複記錄的可能）我們也能複寫ShouldLog方法加入我們自己的異常記錄判斷邏輯以針對不同的場景進行不同的ExceptionLogger呼叫。如果有興趣可以反編譯ExceptionLogger基類別看看，他使用了顯示介面實現，還挺有意思的一個技巧。下面我們來看一個ExceptionLogger使用的例子：
public class ErroLogger : ExceptionLogger
{ public async Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken)
{ var sb = new StringBuilder(); //获取Log组件
ILogger log = LogManager.GetCurrentClassLogger(); var request = context.Request;
sb.AppendLine("URL:"); //获取URL
var url = request.RequestUri.ToString();
sb.AppendLine(url);
log.Error(context.Exception,sb.ToString(),"");
} public override bool ShouldLog(ExceptionLoggerContext context)
{ return context.Exception is DemoException && base.ShouldLog(context);
}
}登入後複製
在這個例子中，我們重寫了ShouldLog，保證了這個ExceptionLogger只記錄DemoException這個類型的異常，並且也呼叫了基類方法，保證不會重複記錄同一個異常。在LogAsync方法中，我透過Log元件記錄了導致異常的請求URL，也記錄了異常訊息。
接下來我們要對這個元件進行註冊：
在App_Start/WebApiConfig.cs檔案中的Register方法中寫入
config.Services.Add(typeof(IExceptionLogger),new ErroLogger());
登入後複製
這樣，一個針對DemoException的異常記錄元件就開發完成並註冊完成了，當Web API執行管道中出現未處理的DemoException異常，均會調用則個組件進行記錄。
接下來我們來寫一個ExceptionHandler，在整個Web API框架中，ExceptionHandler只能提供一個實例，與ExceptionLogger一樣，我們可以繼承ExceptionHandler基類來簡化異常處理，在ExceptionHandler中也提供了ShouldHandle方法來判斷該異常是否應該處理，避免重複處理管道中其他環節重複拋出的異常。我們也提供一個例子：
public class ErrorHandler : ExceptionHandler
{ public override async Task HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
{ if (context.Exception is DemoException)
{
context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.BadRequest,new {Message=context.Exception.Message}));
} else
{
context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.InternalServerError,new {Message = "服务器已被外星人绑架"}));
}
}
}登入後複製
在這個範例中，我們判斷了例外的類型，並根據不同的例外返回客戶端不同的回應內容和不同的HTTP狀態碼。
接著在設定中註冊這個例外處理模組，在App_Start/WebApiConfig.cs檔案中的Register方法中寫入
##
config.Services.Replace(typeof(IExceptionHandler),new ErrorHandler());
登入後複製
就取代了系統預設的ExceptionHandler，可以使用我們自訂的Handler進行異常的處理了。
在異常記錄、處理過程中，我們都碰到對應的異常上下文參數，我們能透過這個參數取得目前請求的上下文，取得請求、回應（小心有時會為空哦）、捕捉到該異常的catch塊資訊等內容，我們可以利用這些資訊來更好地描述、記錄、處理異常。 ###
到這裡ExceptionLogger元件和ExceptionHandler元件簡單的開發就完成了。在開發的過程中我們可以看到，ExceptionLogger負責了全域的例外記錄，在Web API框架管道下出現未處理的異常ExceptionLogger都會進行擷取、記錄。而ExceptionHandler和ExceptionFilter功能是有重疊的，那麼何時使用ExceptionHandler何時使用ExceptionFilter呢？我們可以將兩者的差異列出如下的表格:
# |
ExceptionFilter |
ExceptionHandler |
#作用域 |
Controller、Action |
##全域
|
| 實例數量
|
無限制
|
無限制 |
全域唯一 |
#作用條件 |
|
#Controller
實例化成功之後
#########Web API#######成功加載之後##################### 經過上面的表我們可以看出，如果處理顆粒度細緻到Controller、Action級別時，ExceptionFilter處理起來會更得心應手，他已經能精確定位到某個Action，然後可以針對目前Action做客製化開發。而ExceptionHandler作用域遠大於ExceptionFilter，他處理全域更有優勢。 ###### 關於Web API異常處理的相關內容我就講這麼一些，如果在文章中有任何不正確的地方或者疑問，歡迎大家為我指出。 ###
以上是Asp.Net Web API 異常處理經驗總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！
