循序漸進學.Net Core Web Api開發系列【14】：異常處理

系列目錄

循序漸進學.Net Core Web Api開發系列目錄

 本系列涉及到的原始碼下載地址：https://github.com/seabluescn/Blog_WebApi

 

一、概述

本篇介紹異常處理的知識。由於異常處理的技術應用並不複雜，本篇更多討論異常處理的一些理論知識，包括一些原則、約定和建議。

 

二、異常處理的基本原則

在Win32API程式設計中是沒有異常處理機制的，函式一般都是通過返回一個BOOL型的狀態碼來表達處理是否成功，比如需要通過ID取得一個實體資訊，需要這樣定義：

BOOL GetArticleByID（string ID，out Article article）；

當呼叫失敗時(函式返回false)，其實呼叫者是不知道失敗的原因的，如果需要知道原因，那就要返回一個int型別來表達狀態，-1表示成功，其他都是錯誤碼，這種函式對呼叫者而言簡直是噩夢。

.NET Framework中採用異常處理機制後，情況就好多了，上面的方法定義如下：

Article GetArticleByID（string ID）；

看到這樣的定義，基本上不要看文件也能明白這個方法的含義，另外所有可能失敗的情況都通過異常來進行報告。

所以，對於呼叫者而言，所有與期望不符的結果都可以認為是“異常”。

 對於異常的處理，有幾個基本原則：

1、只處理（catch）預計可能會發生的異常 

      在程式碼中，我們只處理我們預計可能會發生的異常，比如要把一個字串轉換為數字，我們預計可能會發生FormatException異常，那麼我們就Catch該異常，並提供處理辦法。

      這裡的異常應該是我們有能力處理的，其實每一行程式碼我們都預計可能發生OutMemoryException的異常 ，但這個異常發生時，應用是沒有能力處理的，請不要catch它。

2、絕對不要catch根異常Exception

      這個原則和上面的原則其實是很類似的，catch了根異常表示你有能力處理所有未知異常，而且以同一種方式來處理，顯然是不合適的。

     由於考慮不周，我沒有考慮到某個異常，又不允許我catch根異常，實際執行時應該果然報了一個之前沒有預料的異常怎麼辦？很簡單，把這個異常加上就可以了。發生這種事情是因為程式設計者的經驗不足造成的，不能因為這個原因破壞異常處理的原則。

3、如果方法還有呼叫者，應該對異常進行封裝

      如果我們是寫類庫相關的程式碼，主要是提供服務給消費者呼叫的，最好對捕捉到的異常進行封裝，給出和呼叫者重新約定的異常型別。比如我們在DAO層把所有捕捉到的異常處理完成後重新丟擲一個DBOperateException，並提供相關資訊。Control層在呼叫DAO時相對就簡單了，只需處理DBOperateException並把資訊（或處理過的資訊）報告給View就可以了。

下面我們會以一些例項描述我們是如何遵守和打破這些原則的。

 

三、在WebApi開發中的異常處理

 我們要設計一個Controller，實現通過ID來獲取例項物件的功能，由於異常無法通過Http協議進行傳送，所以我們定義了一個ResultObject的返回型別，用於向客戶端傳送呼叫結果。

   public class ResultObject
    {
        public ResultObject()
        {
            state = ResultState.Success;
            ExceptionString = "";
            result = null;
        }

        public ResultState state { get; set; }
        public String ExceptionString { get; set; }

        public Object result { get; set; }
    }

    public enum ResultState
    {
        Success,
        Exception
    }

具體的Controller設計如下： 

public ResultObject GetArticleByID(string id)
        {
            try
            {
                int idn = int.Parse(id);

                Article article = _context.Articles
                    .AsNoTracking()
                    .Where(a => a.ID == id)
                    .Single();

                return new ResultObject
                {
                    result = article
                };
            }
            catch (System.FormatException ex)
            {
                _logger.LogError(ex.Message + "
" + ex.StackTrace);

                return new ResultObject
                {
                    state = ResultState.Exception,
                    ExceptionString = "id必須為數字"
                };
            }
            catch (System.InvalidOperationException ex)
            {
                _logger.LogError(ex.Message + "
" + ex.StackTrace);

                return new ResultObject
                {
                    state = ResultState.Exception,
                    ExceptionString = "未查詢到預料的資料"
                };
            }
            catch(MySql.Data.MySqlClient.MySqlException ex)
            {
                _logger.LogError(ex.Message + "
" + ex.StackTrace);

                return new ResultObject
                {
                    state = ResultState.Exception,
                    ExceptionString = "資料庫異常"
                };
            }
        }

對於上述程式碼，我們預料到可能使用者會輸入字串而不是數字，也能預料到可能查詢不到結果，所以就截獲了這兩個異常。對於ToList這樣的操作，沒有查詢到資料會返回NULL，不會報異常，所以就不應該catch InvalidOperationException。另外，我們可能預料到會發生無法連線資料庫的異常，在此也處理了，由於資料庫連線異常可能在每個方法呼叫時都可能發生。建議提供為統一異常處理。

 

四、全域性未處理異常

設計一個全域性異常處理的中介軟體：

 public class UnifyExceptionMiddleware
    {
        private readonly RequestDelegate _next;
        private readonly ILogger _logger;

        public UnifyExceptionMiddleware(RequestDelegate next, ILogger<UnifyExceptionMiddleware> logger)
        {
            _next = next;
            _logger=logger;
        }

        public async Task Invoke(HttpContext context)
        {
            ResultObject result =null;

            try
            {
                await _next(context);
            }
            catch(MySql.Data.MySqlClient.MySqlException ex)
            {
                _logger.LogError(ex.Message + "
" + ex.StackTrace);

                result = new ResultObject
                {
                    state = ResultState.Exception,
                    ExceptionString = "資料庫異常"
                };
            }
            catch(Exception ex)
            {
                _logger.LogError($"系統發生未處理異常：{ex.StackTrace}");

                result = new ResultObject
                {
                    state = ResultState.Exception,
                    ExceptionString = "系統發生未處理異常"
                };                
            }

            context.Response.StatusCode = 200;
            context.Response.ContentType = "application/json; charset=utf-8";
            context.Response.WriteAsync(JsonConvert.SerializeObject(result));
        }
    }

    public static class VisitLogMiddlewareExtensions
    {
        public static IApplicationBuilder UseUnifyException(this IApplicationBuilder builder)
        {
            return builder.UseMiddleware<UnifyExceptionMiddleware>();
        }
    }

使用該中介軟體

public class Startup
    {
        public Startup(IConfiguration configuration)
        {
            Configuration = configuration;
        }
        public IConfiguration Configuration { get; }
       // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
        public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
        {          
            loggerFactory.AddNLog();  
            app.UseUnifyException();            
            app.UseMvcWithDefaultRoute();            
        }
    }

異常處理的中介軟體要放在MVC中介軟體之前，這樣就可以截獲Contriller內的未處理異常。

 

五、兩點思考

1、為什麼我們處理了根異常Exception

前面提到不要處理根異常，但這裡卻處理了，這是什麼情況？我們說不要處理根異常，是因為不希望某個方法掩蓋了問題，向上級報告一個虛假的狀態，但對於所有處理流程的最上級，可以適當違反該原則。

就應用程式而言，當發生未處理異常時，作業系統會接管該異常的處理，這是微軟推薦的做法，但我們還是常常會進行全域性未處理異常的處理，彈出一個使用者看得懂的提示框，並登記一個異常報告。

對於WebApi而言，介面並不直接面對使用者，但由於異常機制無法通過Http協議進行傳輸，介面的呼叫者就是WebApi的終端使用者了，所有可以對根異常進行捕獲。

這裡有兩種選擇：

1）不捕獲根異常，出現未處理異常時，向呼叫者報500；

2）捕獲根異常，出現未處理異常時，向呼叫者報200，同時報告異常內容。

具體如何選擇，就不是一個技術問題了，主要看團隊的管理規定與約定。某些公司規定介面是不允許報500的，否則是要扣績效的，那隻能捕獲根異常了，畢竟績效最重要對吧。

 

2、異常發生時，應該報告給客戶端什麼樣的狀態碼？

 我們和前端約定使用ResultObject來返回撥用狀態和結果，對於發生“異常”時應該返回什麼樣的狀態碼比較合適呢，這大致也有兩種選擇：

1）一律返回200，通過ResultObject報告介面，欄位不夠可以增加資訊欄位；

2）通過狀態碼返回一些特殊的異常，比如：找不到資源返回404，認證失敗返回401等，未知異常報500等等。

對於WebApi而言推薦使用第一種模式。

  

附：Http Response 返回碼

HTTP協議狀態碼錶示的意思主要分為五類,大體是: 

1××	保留
2××	表示請求成功地接收
3××	為完成請求客戶需進一步細化請求
4××	客戶錯誤
5××	伺服器錯誤

 列舉一些常見的狀態碼： 

200 OK  指示客服端的請求已經成功收到，解析，接受。 

401 Unauthorized  如果請求需要使用者驗證。回送應該包含一個WWW-Authenticate頭欄位用來指明請求資源的許可權。 

403 Forbidden  伺服器接受請求，但是被拒絕處理。 

404 Not Found  伺服器已經找到任何匹配Request-URI的資源。 

500 Internal Server Error  伺服器遭遇異常阻止了當前請求的執行。 

502 Bad Gateway  無效閘道器。 

503 Service Unavailable  因為臨時檔案超載導致伺服器不能處理當前請求。