由于ASP.NET Core應用是一個同時處理多個請求的服務器應用，所以在處理某個請求過程中拋出的異常并不會導致整個應用的終止。出于安全方面的考量，為了避免敏感信息的外泄，客戶端在默認的情況下并不會得到詳細的出錯信息，這無疑會在開發(fā)環(huán)境下增加查錯糾錯的難度。對于生產(chǎn)環(huán)境來說，我們也希望最終用戶能夠根據(jù)具體的錯誤類型得到具有針對性并且友好的錯誤消息。ASP.NET Core提供了相應的中間件幫助我們將定制化的錯誤信息呈現(xiàn)出來，這些中間件都定義在“Microsoft.AspNetCore.Diagnostics”這個NuGet包中。在著重介紹這些中間件之前，我們照理演示幾個簡單的實例讓讀者朋友們對這些中間件的作用有一個大概的了解。[本文已經(jīng)同步到《ASP.NET Core框架揭秘》之中]

目錄
一、顯示開發(fā)者異常頁面
二、顯示定制異常頁面
三、針對響應狀態(tài)碼定制錯誤頁面

一、顯示開發(fā)者異常頁面

一般情況下，如果ASP.NET Core在處理某個請求時出現(xiàn)異常，它一般會返回一個狀態(tài)碼為“500?Internal Server Error”的響應。為了避免一些敏感信息的外泄，詳細的錯誤信息并不會隨著響應發(fā)送給客戶端，所以客戶端只會得到一個很一般化的錯誤消息。以如下這個程序為例，服務端在處理每個請求時都會拋出一個類型為InvalidOperationException的異常。

1: public class Program 2: { 3: public static void Main() 4: { 5: new WebHostBuilder() 6: .UseKestrel() 7: .Configure(app => app.Run(context => Task.FromException(new InvalidOperationException("Manually thrown exception...")))) 8: .Build() 9: .Run(); 10: } 11: }

當我們利用瀏覽器訪問這個應用的時候，總是會得到如下圖所示的這個錯誤頁面。可以看出這個頁面僅僅告訴我們目標應用當前無法正常處理本次請求，除了提供的響應狀態(tài)碼(“HTTP ERROR 500”)之外，它并沒有提供任何有益于差錯糾錯的錯誤信息。

那么有人可能會覺得雖然瀏覽器上沒有顯示出任何詳細的錯誤信息，也許它會隱藏在接收到的HTTP響應報文中。針對通過瀏覽器放出的這個請求，得到的響應內(nèi)容如下所示，我們會發(fā)現(xiàn)響應報文根本沒有主體部分，有限的幾個報頭也并沒有承載任何與錯誤有關的信息。

1: HTTP/1.1 500 Internal Server Error 2: Date: Fri, 09 Dec 2016 23:42:18 GMT 3: Content-Length: 0 4: Server: Kestrel

由于應用并沒有中斷，瀏覽器上也并沒有顯示任何具有針對性的錯誤信息，開發(fā)人員在進行查錯糾錯的時候如何準確定位到作為錯誤根源的那一行代碼呢？具體來說，我們又兩種解決方案，一種就是利用日志，因為ASP.NET Core在進行請求處理時出現(xiàn)的任何錯誤都會被寫入日志，所以我們可以通過注冊相應的LoggerProvider(比如注冊一個ConsoleLoggerProvider將日志直接寫入宿主應用的控制臺)到來獲取寫入的錯誤日志。

至于另一種解決方案，就是直接顯示一個包含錯誤相應信息的錯誤頁面，由于這個頁面是在開發(fā)環(huán)境給開發(fā)者看的，所以我們將這個頁面稱為“開發(fā)者異常頁面(Developer Exception Page)”。針對頁面的自動呈現(xiàn)是利用一個名為DeveloperExceptionPageMiddleware的中間件來完成的，我們可以調(diào)用ApplicationBuilder的擴展方法UseDeveloperExceptionPage來注冊這個中間件。

1: public class Program 2: { 3: public static void Main() 4: { 5: new WebHostBuilder() 6: .UseKestrel() 7: .Configure(app => app 8: .UseDeveloperExceptionPage() 9: .Run(context => Task.FromException(new InvalidOperationException("Manually thrown exception...")))) 10: .Build() 11: .Run(); 12: } 13: }

一旦注冊了這個DeveloperExceptionPageMiddleware中間件，ASP.NET Core應用在處理請求出現(xiàn)的異常信息就會以下圖的形式直接出現(xiàn)在瀏覽器上，我們可以在這個頁面中看到幾乎所有的錯誤信息，包括異常的類型、消息和堆棧信息等。

開發(fā)者異常頁面除了顯示與拋出的異常相關的信息之外，還會以如下圖所示的形式顯示與當前請求上下文相關的信息，其中包括當前請求URL攜帶的所有查詢字符串、所有請求報頭以及Cookie的內(nèi)容。如此詳盡的信息無疑會極大地幫助開發(fā)人員盡快地找出錯誤的根源。

通過DeveloperExceptionPageMiddleware中間件呈現(xiàn)的錯誤頁面僅僅是供開發(fā)人員使用的，詳細的錯誤信息往往會攜帶一些敏感的信息，所以務必記住只有在開發(fā)環(huán)境才能注冊這個中間件，如下所示的代碼片段體現(xiàn)了針對DeveloperExceptionPageMiddleware中間件正確的注冊方式。

1: new WebHostBuilder() 2: .UseStartup() 3: … 4: 5: public class Startup 6: { 7: public void Configure(IApplicationBuilder app, IHostingEnvironment env) 8: { 9: if (env.IsDevelopment()) 10: { 11: app.UseDeveloperExceptionPage(); 12: } 13: } 14: }

二、顯示定制異常頁面

DeveloperExceptionPageMiddleware中間件通過將異常詳細信息和基于當前請求的內(nèi)容直接呈現(xiàn)在錯誤頁面中，這為開發(fā)人員的糾錯診斷提供了極大的便利。但是在生產(chǎn)環(huán)境下，我們傾向于為最終的用戶呈現(xiàn)一個定制的錯誤頁面，而這可以通過注冊另一個名為ExceptionHandlerMiddleware的中間件來實現(xiàn)。顧名思義，這個中間件旨在提供一個異常處理器(Exception Handler)來處理拋出的異常。實際上這個所謂的異常處理器就是一個類型為RequestDelegate的委托對象，ExceptionHandlerMiddleware中間件捕捉到拋出的異常后利用它來響應當前的請求。

還是以上面創(chuàng)建的這個總是會拋出一個 InvalidOperationException異常的應用為例。我們按照如下的形式調(diào)用ApplicationBuilder的擴展方法UseExceptionHandler注冊了上述的這個ExceptionHandlerMiddleware中間件。這個擴展方法具有一個ExceptionHandlerOptions類型的參數(shù)，它的ExceptionHandler屬性返回的就是這個作為異常處理器的RequestDelegate對象。

1: public class Program 2: { 3: public static void Main() 4: { 5: RequestDelegate handler = async context => await context.Response.WriteAsync("Unhandled exception occurred!"); 6:? 7: new WebHostBuilder() 8: .UseKestrel() 9: .Configure(app => app.UseExceptionHandler(new ExceptionHandlerOptions { ExceptionHandler = handler}) 10: .Run(context => Task.FromException(new InvalidOperationException("Manually thrown exception...")))) 11: .Build() 12: .Run(); 13: } 14: }

如上面的代碼片段所示，這個作為異常處理器的RequestDelegate僅僅是將一個簡單的錯誤消息(“Unhandled exception occurred!”)作為響應的內(nèi)容。當我們利用瀏覽器訪問該應用的時候，這個定制的錯誤消息將會以如圖4所示的形式直接呈現(xiàn)在瀏覽器上。

最終作為異常處理器的是一個類型為RequestDelegate的委托對象，而ApplicationBuilder具有創(chuàng)建這個委托對象的能力。具體來說，我們可以根據(jù)異常處理的需要將相應的中間件注冊到某個ApplicationBuilder對象上，并最終利用這個ApplicationBuilder根據(jù)注冊的中間件創(chuàng)建出作為異常處理器的RequestDelegate對象。如果異常處理需要通過一個或者多個中間件來完成，我們可以按照如下的形式調(diào)用另一個UseExceptionHandler方法重載。這個方法的參數(shù)類型為Action，我們調(diào)用它的Run方法注冊了一個中間件來響應一個簡單的錯誤消息。

1: public class Program 2: { 3: public static void Main() 4: { 5: new WebHostBuilder() 6: .UseKestrel() 7: .Configure(app => app.UseExceptionHandler(builder=>builder.Run(async context => await context.Response.WriteAsync("Unhandled exception occurred!"))) 8: .Run(context => Task.FromException(new InvalidOperationException("Manually thrown exception...")))) 9: .Build() 10: .Run(); 11: } 12: }

上面這兩種異常處理的形式都體現(xiàn)在提供一個RequestDelegate的委托對象來處理拋出的異常并完成最終的響應。如果應用已經(jīng)設置了一個錯誤頁面，并且這個錯誤頁面具有一個固定的路徑，那么我們在進行異常處理的時候就沒有必要提供這個RequestDelegate對象，而只需要重定向到錯誤頁面指向的路徑即可。這種采用服務端重定向的異常處理方式可以采用如下的形式調(diào)用另一個UseExceptionHandler方法重載來完成，這個方法的參數(shù)表示的就是重定向的目標路徑(“/error”)，我們針對這個路徑注冊了一個路由來響應定制的錯誤消息。

1: public class Program 2: { 3: public static void Main() 4: { 5: new WebHostBuilder() 6: .UseKestrel() 7: .ConfigureServices(svcs=>svcs.AddRouting()) 8: .Configure(app => app 9: .UseExceptionHandler("/error") 10: .UseRouter(builder=>builder.MapRoute("error", async context => await context.Response.WriteAsync("Unhandled exception occurred!"))) 11: .Run(context => Task.FromException(new InvalidOperationException("Manually thrown exception...")))) 12: .Build() 13: .Run(); 14: } 15: }

三、針對響應狀態(tài)碼定制錯誤頁面

由于Web應用采用HTTP通信協(xié)議，所以我們應該盡可能低迎合HTTP標準并將定義在協(xié)議規(guī)范中的語義應用到應用中。對于異常或者錯誤的語義表達在HTTP協(xié)議層面主要體現(xiàn)在響應報文的狀態(tài)碼上，具體來說HTTP通信的錯誤大體分為如下兩種類型：

• 客戶端錯誤：表示因客戶端提供不正確的請求信息而導致服務器不能正常處理請求，響應狀態(tài)碼范圍在400~499之間。

• 服務端錯誤：表示服務器在處理請求過程中因自身的問題而發(fā)生錯誤，響應狀態(tài)碼在500~509之間。

正是因為響應狀態(tài)碼是對錯誤或者異常語義最重要的表達，所以在很多情況下我們需要針對不同的響應狀態(tài)碼來定制顯示的錯誤信息。針對響應狀態(tài)碼對錯誤頁面的定制可以借助一個類型為StatusCodePagesMiddleware的中間件來實現(xiàn)，我們可以調(diào)用ApplicationBuilder相應的擴展方法來注冊這個中間件。

DeveloperExceptionPageMiddleware和ExceptionHandlerMiddleware中間件都是在后續(xù)請求處理過程中拋出異常的情況下才會被調(diào)用，而StatusCodePagesMiddleware被調(diào)用的前提是后續(xù)請求助理過程中產(chǎn)生一個錯誤響應狀態(tài)碼(范圍在400~599之間)。如果僅僅希望顯示一個統(tǒng)一的錯誤頁面，我們可以按照如下的形式調(diào)用擴展方法UseStatusCodePages注冊這個中間件，傳入該方法的兩個參數(shù)分別表示響應采用的媒體類型和主體內(nèi)容。

1: public class Program 2: { 3: public static void Main() 4: { 5: new WebHostBuilder() 6: .UseKestrel() 7: .Configure(app=>app 8: .UseStatusCodePages("text/plain", "Error occurred ({0})") 9: .Run(context=> Task.Run(()=>context.Response.StatusCode = 500))) 10: .Build() 11: .Run(); 12: } 13: }

如上面的代碼片段所示，應用在處理請求的時候總是會將響應狀態(tài)碼設置為500，所以最終的響應內(nèi)容將由注冊的StatusCodePagesMiddleware中間件來提供。我們調(diào)用UseStatusCodePages方法的時候?qū)㈨憫拿襟w類型設置為“text/plain”，并將一段簡單的錯誤消息作為了響應的主體內(nèi)容。值得一提的時候，作為響應內(nèi)容的字符串可以包含一個占位符({0})，StatusCodePagesMiddleware中間件最終會采用當前響應狀態(tài)碼來替換它。如果我們利用瀏覽器來訪問這個應用，將會得到如下圖所示的錯誤頁面。

如果我們希望針對不同的錯誤狀態(tài)碼顯示不同的錯誤頁面，那么我們就需要將具體的請求處理邏輯實現(xiàn)在一個的狀態(tài)碼錯誤處理器中，并最終提供給StatusCodePagesMiddleware中間件。這個所謂的狀態(tài)碼錯誤處理器體現(xiàn)為一個類型為Func的委托對象，作為輸入的StatusCodeContext對象是對當前HttpContext的封裝，同時承載著其他一些與錯誤處理相關的選項設置，我們將在本系列后續(xù)部分對這個類型進行詳細介紹。

對于如下這個應用來說，它在處理任意一個請求是總是會隨機地選擇一個400~599之間的整數(shù)作為響應的狀態(tài)碼，所以客戶端返回的響應內(nèi)容總是通過注冊的StatusCodePagesMiddleware中間件來提供。我們在調(diào)用另一個UseStatusCodePages方法重載的時候，為注冊的中間件指定了一個Func對象作為狀態(tài)碼錯誤處理器。

1: public class Program 2: { 3: private static Random _random = new Random(); 4: 5: public static void Main() 6: { 7: Func handler = async context => { 8: var response = context.HttpContext.Response; 9: if (response.StatusCode < 500) 10: { 11: await response.WriteAsync($"Client error ({response.StatusCode})"); 12: } 13: else 14: { 15: await response.WriteAsync($"Server error ({response.StatusCode})"); 16: } 17: }; 18: new WebHostBuilder() 19: .UseKestrel() 20: .Configure(app => app 21: .UseStatusCodePages(handler) 22: .Run(context => Task.Run(() => context.Response.StatusCode = _random.Next(400,599)))) 23: .Build() 24: .Run(); 25: } 26: }

我們指定的狀態(tài)碼錯誤處理器在處理請求的時候，根據(jù)響應狀態(tài)碼將錯誤分成客戶端錯誤和服務端錯誤兩種類型，并選擇針對性的錯誤消息作為響應內(nèi)容。當我們利用瀏覽器訪問這個應用的時候，顯示的錯誤消息將由響應狀態(tài)碼來決定。

在ASP.NET Core的世界里，針對請求的處理總是體現(xiàn)為一個RequestDelegate對象。如果請求的處理需要借助一個或者多個中間件來完成，我們可以將它們注冊到ApplicationBuilder對象上并利用它將中間件管道轉(zhuǎn)換成一個RequestDelegate對象。用于注冊StatusCodePagesMiddleware中間件的UseStatusCodePage方法還具有另一個重載，它允許我們采用這種方式來創(chuàng)建一個RequestDelegate對象來完成最終的請求處理工作，所以上面演示的這個應用完全可以改寫成如下的形式。

1: public class Program 2: { 3: private static Random _random = new Random(); 4: public static void Main() 5: { 6: RequestDelegate handler = async context => 7: { 8: var response = context.Response; 9: if (response.StatusCode < 500) 10: { 11: await response.WriteAsync($"Client error ({response.StatusCode})"); 12: } 13: else 14: { 15: await response.WriteAsync($"Server error ({response.StatusCode})"); 16: } 17: }; 18: new WebHostBuilder() 19: .UseKestrel() 20: .Configure(app => app 21: .UseStatusCodePages(builder=>builder.Run(handler)) 22: .Run(context => Task.Run(() => context.Response.StatusCode = _random.Next(400, 599)))) 23: .Build() 24: .Run(); 25: } 26: }

總結

以上是生活随笔為你收集整理的asp 开发app_ASP.NET Core应用的错误处理[1]：三种呈现错误页面的方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。