ASP.NET Core應用錯誤處理之ExceptionHandlerMiddleware中間件呈現(xiàn)“定制化錯誤頁面”

更新時間：2019年01月03日 09:55:53 作者：大內(nèi)老A

這篇文章主要給大家介紹了關于ASP.NET Core應用錯誤處理之ExceptionHandlerMiddleware中間件呈現(xiàn)“定制化錯誤頁面”的相關資料，文中通過示例代碼介紹的非常詳細，需要的朋友可以參考借鑒，下面來一起看看吧

前言

DeveloperExceptionPageMiddleware中間件利用呈現(xiàn)出來的錯誤頁面實現(xiàn)拋出異常和當前請求的詳細信息以輔助開發(fā)人員更好地進行糾錯診斷工作，而ExceptionHandlerMiddleware中間件則是面向最終用戶的，我們可以利用它來顯示一個友好的定制化的錯誤頁面。按照慣例，我們還是先來看看ExceptionHandlerMiddleware的類型定義。

 public class ExceptionHandlerMiddleware
 { 
 public ExceptionHandlerMiddleware(RequestDelegate next, ILoggerFactory loggerFactory, IOptions<ExceptionHandlerOptions> options, DiagnosticSource diagnosticSource); 
 public Task Invoke(HttpContext context);
 }
 
 public class ExceptionHandlerOptions
 {
 public RequestDelegate ExceptionHandler { get; set; }
 public PathString  ExceptionHandlingPath { get; set; }
 }

與DeveloperExceptionPageMiddleware類似，我們在創(chuàng)建一個ExceptionHandlerMiddleware對象的時候同樣需要提供一個攜帶配置選項的對象，從上面的代碼可以看出這是一個ExceptionHandlerOptions。具體來說，一個ExceptionHandlerOptions對象通過其ExceptionHandler屬性提供了一個最終用來處理請求的RequestDelegate對象。如果希望發(fā)生異常后自動重定向到某個指定的路徑，我們可以利用ExceptionHandlerOptions對象的ExceptionHandlingPath屬性來指定這個路徑。我們一般會調(diào)用ApplicationBuilder的擴展方法UseExceptionHandler來注冊ExceptionHandlerMiddleware中間件，這些重載的UseExceptionHandler方法會采用如下的方式完整中間件的注冊工作。

 public static class ExceptionHandlerExtensions
 {
 public static IApplicationBuilder UseExceptionHandler(this IApplicationBuilder app)=> app.UseMiddleware<ExceptionHandlerMiddleware>();
 
 public static IApplicationBuilder UseExceptionHandler(this IApplicationBuilder app, ExceptionHandlerOptions options) 
 => app.UseMiddleware<ExceptionHandlerMiddleware>(Options.Create(options));
 
 public static IApplicationBuilder UseExceptionHandler(this IApplicationBuilder app, string errorHandlingPath)
 { 
  return app.UseExceptionHandler(new  {
  ExceptionHandlingPath = new PathString(errorHandlingPath)
  });
 }
 
 public static IApplicationBuilder UseExceptionHandler(this IApplicationBuilder app, Action<IApplicationBuilder> configure)
 {
  IApplicationBuilder newBuilder = app.New();
  configure(newBuilder);
 
  return app.UseExceptionHandler(new ExceptionHandlerOptions
  {
  ExceptionHandler = newBuilder.Build()
  });
 } 
 }

一、異常處理器

ExceptionHandlerMiddleware中間件處理請求的本質就是在后續(xù)請求處理過程中出現(xiàn)異常的情況下采用注冊的異常處理器來處理并響應請求，這個異常處理器就是我們再熟悉不過的RequestDelegate對象。該中間件采用的請求處理邏輯大體上可以通過如下所示的這段代碼來體現(xiàn)。

 public class ExceptionHandlerMiddleware
 {
 private RequestDelegate  _next;
 private ExceptionHandlerOptions _options;
 
 public ExceptionHandlerMiddleware(RequestDelegate next, IOptions<ExceptionHandlerOptions> options,…)
 {
  _next  = next;
  _options = options.Value;
  …
 }
 
 public async Task Invoke(HttpContext context)
 {
  try
  {
  await _next(context);
  }
  catch 
  {
  context.Response.StatusCode = 500;
  context.Response.Clear();
  if (_options.ExceptionHandlingPath.HasValue)
  {
   context.Request.Path = _options.ExceptionHandlingPath;
  }
  RequestDelegate handler = _options.ExceptionHandler ?? _next;
  await handler(context);
  }
 }
 }

如上面的代碼片段所示，如果后續(xù)的請求處理過程中出現(xiàn)異常，ExceptionHandlerMiddleware中間件會利用一個作為異常處理器的RequestDelegate對象來完成最終的請求處理工作。如果在創(chuàng)建ExceptionHandlerMiddleware時提供的ExceptionHandlerOptions攜帶著這么一個RequestDelegate對象，那么它將作為最終使用的異常處理器，否則作為異常處理器的實際上就是后續(xù)的中間件。換句話說，如果我們沒有通過ExceptionHandlerOptions顯式指定一個異常處理器，ExceptionHandlerMiddleware中間件會在后續(xù)管道處理請求拋出異常的情況下將請求再次傳遞給后續(xù)管道。

當ExceptionHandlerMiddleware最終利用異常處理器來處理請求之前，它會對請求做一些前置處理工作，比如它會將響應狀態(tài)碼設置為500，比如清空當前所有響應內(nèi)容等。如果我們利用ExceptionHandlerOptions的ExceptionHandlingPath屬性設置了一個重定向路徑，它會將該路徑設置為當前請求的路徑。除了這些，ExceptionHandlerMiddleware中間件實際上做了一些沒有反應在上面這段代碼片段中的工作。

二、異常的傳遞與請求路徑的恢復

由于ExceptionHandlerMiddleware中間件總會利用一個作為異常處理器的RequestDelegate對象來完成最終的異常處理工作，為了讓后者能夠得到拋出的異常，該中間件應該采用某種方式將異常傳遞給它。除此之外，由于ExceptionHandlerMiddleware中間件會改變當前請求的路徑，當整個請求處理完成之后，它必須將請求路徑恢復成原始的狀態(tài)，否則前置的中間件就無法獲取到正確的請求路徑。

請求處理過程中拋出的異常和原始請求路徑的恢復是通過相應的特性完成的。具體來說，傳遞這兩者的特性分別叫做ExceptionHandlerFeature和ExceptionHandlerPathFeature，對應的接口分別為IExceptionHandlerFeature和IExceptionHandlerPathFeature，如下面的代碼片段所示，后者繼承前者。默認使用的ExceptionHandlerFeature實現(xiàn)了這兩個接口。

 public interface IExceptionHandlerFeature
 {
 Exception Error { get; }
 }
 
 public interface IExceptionHandlerPathFeature : IExceptionHandlerFeature
 {
 string Path { get; }
 }
 
 public class ExceptionHandlerFeature : IExceptionHandlerPathFeature, 
 {
 public Exception Error { get; set; }
 public string Path { get; set; }
 }

當ExceptionHandlerMiddleware中間件將代碼當前請求的HttpContext傳遞給請求處理器之前，它會按照如下所示的方式根據(jù)拋出的異常的原始的請求路徑創(chuàng)建一個ExceptionHandlerFeature對象，該對象最終被添加到HttpContext之上。當整個請求處理流程完全結束之后，ExceptionHandlerMiddleware中間件會借助這個特性得到原始的請求路徑，并將其重新應用到當前請求上下文上。

 public class ExceptionHandlerMiddleware
 {
  ...
  public async Task Invoke(HttpContext context)
  {
   try
   {
    await _next(context);
   }
   catch(Exception ex)
   {
    context.Response.StatusCode = 500;
 
    var feature = new ExceptionHandlerFeature()
    {
     Error = ex,
     Path = context.Request.Path,
    };
    context.Features.Set<IExceptionHandlerFeature>(feature);
    context.Features.Set<IExceptionHandlerPathFeature>(feature);
 
    if (_options.ExceptionHandlingPath.HasValue)
    {
     context.Request.Path = _options.ExceptionHandlingPath;
    }
    RequestDelegate handler = _options.ExceptionHandler ?? _next;
 
    try
    {
     await handler(context);
    }
    finally
    {
     context.Request.Path = originalPath;
    }
   }
  }
 }

在具體進行異常處理的時候，我們可以從當前HttpContext中提取這個ExceptionHandlerFeature對象，進而獲取拋出的異常和原始的請求路徑。如下面的代碼所示，我們利用HandleError方法來呈現(xiàn)一個定制的錯誤頁面。在這個方法中，我們正式借助于這個ExceptionHandlerFeature特性得到拋出的異常，并將它的類型、消息以及堆棧追蹤顯示出來。

 public class Program
 {
  public static void Main()
  {
   new WebHostBuilder()
    .UseKestrel()
    .ConfigureServices(svcs=>svcs.AddRouting())
    .Configure(app => app
     .UseExceptionHandler("/error")
     .UseRouter(builder=>builder.MapRoute("error", HandleError))
     .Run(context=> Task.FromException(new InvalidOperationException("Manually thrown exception"))))
    .Build()
    .Run();
  }
 
  private async static Task HandleError(HttpContext context)
  {
   context.Response.ContentType = "text/html";
   Exception ex = context.Features.Get<IExceptionHandlerPathFeature>().Error;
 
   await context.Response.WriteAsync("<html><head><title>Error</title></head><body>");
   await context.Response.WriteAsync($"<h3>{ex.Message}</h3>");
   await context.Response.WriteAsync($"<p>Type: {ex.GetType().FullName}");
   await context.Response.WriteAsync($"<p>StackTrace: {ex.StackTrace}");
   await context.Response.WriteAsync("</body></html>");
  }

在上面這個應用中，我們注冊了一個模板為“error”的路由指向這個HandleError方法。對于通過調(diào)用擴展方法UseExceptionHandler注冊的ExceptionHandlerMiddleware來說，我們將該路徑設置為異常處理路徑。那么對于任意從瀏覽器發(fā)出的請求，都會得到如下圖所示的錯誤頁面。

三、清除緩存

對于一個用于獲取資源的GET請求來說，如果請求目標是一個相對穩(wěn)定的資源，我們可以采用客戶端緩存的方式避免相同資源的頻繁獲取和傳輸。對于作為資源提供者的Web應用來說，當它在處理請求的時候，除了將目標資源作為響應的主體內(nèi)容之外，它還需要設置用于控制緩存的相關響應報頭。由于緩存在大部分情況下只適用于成功的響應，如果服務端在處理請求過程中出現(xiàn)異常，之前設置的緩存報頭是不應該出現(xiàn)在響應報文中。對于ExceptionHandlerMiddleware中間件來說，清楚緩存報頭也是它負責的一項重要工作。

我們同樣可以通過一個簡單的實例來演示ExceptionHandlerMiddleware中間件針對緩存響應報頭的清除。在如下這個應用中，我們將針對請求的處理實現(xiàn)在Invoke方法中，它有50%的可能會拋出異常。不論是返回正常的響應內(nèi)容還是拋出異常，這個方法都會先設置一個“Cache-Control”的響應報頭，并將緩存時間設置為1個小時（“Cache-Control: max-age=3600”）。

 public class Program
 {
  public static void Main()
  {
   new WebHostBuilder()
    .UseKestrel()
    .ConfigureServices(svcs => svcs.AddRouting())
    .Configure(app => app
     .UseExceptionHandler(builder => builder.Run(async context => await context.Response.WriteAsync("Error occurred!")))
     .Run(Invoke))
    .Build()
    .Run();
  }
 
  private static Random _random = new Random();
  private async static Task Invoke(HttpContext context)
  {
   context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue
   {
    MaxAge = TimeSpan.FromHours(1)
   };
 
   if (_random.Next() % 2 == 0)
   {
    throw new InvalidOperationException("Manually thrown exception...");
   }
   await context.Response.WriteAsync("Succeed...");
  }
 }

通過調(diào)用擴展方法 UseExceptionHandler注冊的ExceptionHandlerMiddleware中間件在處理異常時會響應一個內(nèi)容為“Error occurred!”的字符串。如下所示的兩個響應報文分別對應于正常響應和拋出異常的情況，我們會發(fā)現(xiàn)程序中設置的緩存報頭“Cache-Control: max-age=3600”只會出現(xiàn)在狀態(tài)碼為“200 OK”的響應中。至于狀態(tài)碼為“500 Internal Server Error”的響應中，則會出現(xiàn)三個與緩存相關的報頭，它們的目的都會為了禁止緩存（或者指示緩存過期）。

 HTTP/1.1 200 OK
 Date: Sat, 17 Dec 2016 14:39:02 GMT
 Server: Kestrel
 Cache-Control: max-age=3600
 Content-Length: 10
 
 Succeed...
 
 
 HTTP/1.1 500 Internal Server Error
 Date: Sat, 17 Dec 2016 14:38:39 GMT
 Server: Kestrel
 Cache-Control: no-cache
 Pragma: no-cache
 Expires: -1
 Content-Length: 15
 
 Error occurred!

ExceptionHandlerMiddleware中間件針對緩存響應報頭的清除體現(xiàn)在如下所示的代碼片段中。我們可以看出它通過調(diào)用HttpResponse的OnStarting方法注冊了一個回調(diào)（ClearCacheHeaders），上述的這三個緩存報頭在這個回調(diào)中設置的。除此之外，我們還看到這個回調(diào)方法還會清除ETag報頭，這也很好理解：由于目標資源沒有得到正常的響應，表示資源“簽名”的ETag報頭自然不應該出現(xiàn)在響應報文中。

 public class ExceptionHandlerMiddleware
 {
  ...
  public async Task Invoke(HttpContext context)
  {
   try
   {
    await _next(context);
   }
   catch (Exception ex)
   {
    …
    context.Response.OnStarting(ClearCacheHeaders, context.Response);
    RequestDelegate handler = _options.ExceptionHandler ?? _next;
    await handler(context);
   }
  }
 
  private Task ClearCacheHeaders(object state)
  {
   var response = (HttpResponse)state;
   response.Headers[HeaderNames.CacheControl]  = "no-cache";
   response.Headers[HeaderNames.Pragma]   = "no-cache";
   response.Headers[HeaderNames.Expires]   = "-1";
   response.Headers.Remove(HeaderNames.ETag);
   return Task.CompletedTask;
  }
 }

總結

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

您可能感興趣的文章:

.NET6環(huán)境下實現(xiàn)MQTT通信及詳細代碼演示
本文詳細講解了.NET6環(huán)境下實現(xiàn)MQTT通信的方法，文中通過示例代碼介紹的非常詳細。對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下
2022-07-07
實現(xiàn)基于事件通知的.Net套接字
實現(xiàn)基于事件通知的.Net套接字...
2006-09-09
微信公眾平臺開發(fā)之地理位置.Net代碼解析
這篇文章主要為大家詳細解析了微信公眾平臺開發(fā)之地理位置.Net代碼，感興趣的小伙伴們可以參考一下
2016-06-06
asp.net 文件上傳與刷新與asp.net頁面與iframe之間的數(shù)據(jù)傳輸
眾所周知微軟所提供的updatepanel不能支持文件上傳的異步刷新，但是往往當你在項目中的其他頁面實現(xiàn)了異步刷新之后，客戶就會問你為什么有文件上傳的頁面就不能實現(xiàn)異步刷新呢？這時我們可能說一堆理由，但是最后大部分還是會妥協(xié)于客戶。
2009-12-12
XmlReader 讀取器讀取內(nèi)存流 MemoryStream 的注意事項
XmlReader 讀取器讀取內(nèi)存流 MemoryStream 的注意事項...
2007-04-04
asp.net微信開發(fā)（已關注用戶管理）
這篇文章主要介紹了asp.net微信開發(fā)中有關已關注用戶管理的相關內(nèi)容，需要的朋友可以參考下
2015-11-11
asp.net安全、實用、簡單的大容量存儲過程分頁
昨晚研究到2點多，對網(wǎng)絡上主流的分頁存儲過程大體看了一遍，但對安全以及如何使用很多文章都沒有過多的提及，而我要在這些文章的基礎上總結出一個比較實用的分頁存儲過程，方便大家在以后的項目中使用。
2009-04-04
asp.net 因為數(shù)據(jù)庫正在使用的解決方法
因為數(shù)據(jù)庫正在使用,所以未能獲得對數(shù)據(jù)庫的排它訪問權？
2009-02-02
.NET性能優(yōu)化之為結構體數(shù)組使用StructLinq的問題解析
這篇文章主要介紹了.NET性能優(yōu)化為結構體數(shù)組使用StructLinq,本系列的主要目的是告訴大家在遇到性能問題時，有哪些方案可以去優(yōu)化；并不是要求大家一開始就使用這些方案來提升性能，需要的朋友可以參考下
2022-05-05
asp.net+js實現(xiàn)批量編碼與解碼的方法
這篇文章主要介紹了asp.net+js實現(xiàn)批量編碼與解碼的方法,涉及前端的jquery post提交及后臺C#處理實現(xiàn)批量編碼與解碼的相關技巧,需要的朋友可以參考下
2016-03-03