在本文中，我將講解如何通過(guò)自定義ExceptionHandlerMiddleware，以便在中間件管道中發(fā)生錯(cuò)誤時(shí)創(chuàng)建自定義響應(yīng)，而不是提供一個(gè)“重新執(zhí)行”管道的路徑。

作者：依樂(lè)祝
譯文：https://www.cnblogs.com/yilezhu/p/12497937.html
原文：https://andrewlock.net/creating-a-custom-error-handler-middleware-function/

Razor頁(yè)面中的異常處理

所有的.NET應(yīng)用程序都有可能會(huì)產(chǎn)生錯(cuò)誤，并且不幸地引發(fā)異常，因此在ASP.NET中間件管道中處理這些異常顯得非常重要。服務(wù)器端呈現(xiàn)的應(yīng)用程序（如Razor Pages）通常希望捕獲這些異常并重定向到一個(gè)錯(cuò)誤頁(yè)面。

例如，如果您創(chuàng)建一個(gè)使用Razor Pages（dotnet new webapp）的新Web應(yīng)用程序，您將在Startup.Configure中看到如下的中間件配置：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {if (env.IsDevelopment()){app.UseDeveloperExceptionPage();}else{app.UseExceptionHandler("/Error");}// .. other middleware not shown }

在Development環(huán)境中運(yùn)行時(shí)，應(yīng)用程序?qū)⒉东@處理請(qǐng)求時(shí)引發(fā)的所有異常，并使用一個(gè)非常有用的DeveloperExceptionMiddleware方法將其以網(wǎng)頁(yè)的形式進(jìn)行顯示：

開(kāi)發(fā)人員例外頁(yè)面

這在本地開(kāi)發(fā)期間非常有用，因?yàn)樗鼓梢钥焖贆z查堆棧跟蹤，請(qǐng)求標(biāo)頭，路由詳細(xì)信息以及其他內(nèi)容。

當(dāng)然，這些都是您不想在生產(chǎn)中公開(kāi)的敏感信息。因此，當(dāng)不在開(kāi)發(fā)階段時(shí)，我們將使用其他異常處理程序ExceptionHandlerMiddleware。此中間件允許您提供一個(gè)請(qǐng)求路徑，默認(rèn)情況下是"/Error"，并使用它“重新執(zhí)行”中間件管道，以生成最終響應(yīng)：

使用以下命令重新執(zhí)行管道

Razor Pages應(yīng)用程序的最終結(jié)果是，每當(dāng)生產(chǎn)中發(fā)生異常時(shí)，就會(huì)返回這個(gè)Error.cshtml?的Razor 頁(yè)面：

生產(chǎn)中的例外頁(yè)面

這涵蓋了razor 頁(yè)面的異常處理，但是Web API呢？

Web API的異常處理

Web API模板（dotnet new webapi）中的默認(rèn)異常處理類似于Razor Pages使用的異常處理，但有一個(gè)重要的區(qū)別：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {if (env.IsDevelopment()){app.UseDeveloperExceptionPage();}// .. other middleware not shown }

如您所見(jiàn)DeveloperExceptionMiddleware，在Development環(huán)境中仍會(huì)添加，但是在生產(chǎn)中根本沒(méi)有添加錯(cuò)誤處理！這沒(méi)有聽(tīng)起來(lái)那么糟糕：即使沒(méi)有異常處理中間件，ASP.NET Core也會(huì)在其底層架構(gòu)中捕獲該異常，將其記錄下來(lái)，并向客戶端返回一個(gè)空白的500響應(yīng)：

一個(gè)例外

如果您正在使用該[ApiController]屬性（你可能應(yīng)該這樣使用），并且該錯(cuò)誤來(lái)自您的Web API控制器，那么ProblemDetails默認(rèn)情況下會(huì)得到一個(gè)結(jié)果，或者您可以進(jìn)一步對(duì)其進(jìn)行自定義。

對(duì)于Web API客戶端來(lái)說(shuō)，這實(shí)際上還不錯(cuò)。您的API使用者應(yīng)能夠處理錯(cuò)誤響應(yīng)，因此最終用戶將不會(huì)看到上面的“中斷”頁(yè)面。但是，它通常不是那么簡(jiǎn)單。

例如，也許您使用的是錯(cuò)誤的標(biāo)準(zhǔn)格式，例如ProblemDetails格式。如果您的客戶期望所有錯(cuò)誤都具有該格式，那么在某些情況下生成的空響應(yīng)很可能導(dǎo)致客戶端中斷。同樣，在Development環(huán)境中，當(dāng)客戶端期望返回JSON時(shí)而你返回一個(gè)HTML開(kāi)發(fā)人員異常頁(yè)面，這可能會(huì)導(dǎo)致問(wèn)題！

官方文檔中描述了一種解決方案，建議您創(chuàng)建ErrorController并具有兩個(gè)終結(jié)點(diǎn)的：

[ApiController] public class ErrorController : ControllerBase {[Route("/error-local-development")]public IActionResult ErrorLocalDevelopment() => Problem(); // Add extra details here[Route("/error")]public IActionResult Error() => Problem(); }

然后使用Razor Pages應(yīng)用程序中使用的相同“重新執(zhí)行”功能來(lái)生成響應(yīng)：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {if (env.IsDevelopment()){app.UseExceptionHandler("/error-local-development");}else{app.UseExceptionHandler("/error");}// .. other middleware }

這可以正常工作，但是對(duì)于使用生成異常的同一基礎(chǔ)結(jié)構(gòu)（例如Razor Pages或MVC）來(lái)生成異常消息，總有一些困擾我。由于被第二次拋出異常，我多次被失敗的錯(cuò)誤響應(yīng)所困擾！因此，我喜歡采取稍微不同的方法。

使用ExceptionHandler代替ExceptionHandlingPath

當(dāng)我第一次開(kāi)始使用ASP.NET Core時(shí)，解決此問(wèn)題的方法是編寫自己的自定義ExceptionHandler中間件來(lái)直接生成響應(yīng)?！疤幚懋惓２皇悄敲措y，對(duì)吧”？

事實(shí)證明，這要復(fù)雜得多（我知道，令人震驚）。您需要處理各種邊緣情況，例如：

• 如果在發(fā)生異常時(shí)響應(yīng)已經(jīng)開(kāi)始發(fā)送，則您將無(wú)法攔截它。

• 如果在EndpointMiddleware發(fā)生異常時(shí)已執(zhí)行，則需要對(duì)選定的端點(diǎn)進(jìn)行一些處理

• 您不想緩存錯(cuò)誤響應(yīng)

ExceptionHandlerMiddleware處理所有這些情況，所以重新寫你自己的版本不是一條要走的路。幸運(yùn)的是，盡管通常顯示的方法是為中間件提供重新執(zhí)行的路徑，但還有另一種選擇-直接提供處理函數(shù)。

在ExceptionHandlerMiddleware中有一個(gè)ExceptionHandlerOptions參數(shù)。該選項(xiàng)對(duì)象具有兩個(gè)屬性：

public class ExceptionHandlerOptions {public PathString ExceptionHandlingPath { get; set; }public RequestDelegate ExceptionHandler { get; set; } }

當(dāng)你向UseExceptionHandler(path)方法提供重新執(zhí)行的路徑時(shí)，實(shí)際上是在options對(duì)象上設(shè)置ExceptionHandlingPath。同樣的，如果需要的話，您可以設(shè)置ExceptionHandler屬性，并使用UseExceptionHandler()將ExceptionHandlerOptions的實(shí)例直接傳遞給中間件：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {app.UseExceptionHandler(new ExceptionHandlerOptions{ExceptionHandler = // .. to implement});// .. othe middleware }

另外，您可以使用UseExceptionHandler()的另一個(gè)重載方法并配置一個(gè)迷你中間件管道來(lái)生成響應(yīng)：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env) {app.UseExceptionHandler(err => err.UseCustomErrors(env)); // .. to implement// .. othe middleware }

兩種方法都是等效的，因此更多是關(guān)于喜好的問(wèn)題。在本文中，我將使用第二種方法并實(shí)現(xiàn)該UseCustomErrors()功能。

創(chuàng)建自定義異常處理函數(shù)

對(duì)于此示例，我將假設(shè)我們?cè)谥虚g件管道中遇到異常時(shí)需要生成一個(gè)ProblemDetails的對(duì)象。我還要假設(shè)我們的API僅支持JSON。這就避免了我們不必?fù)?dān)心XML內(nèi)容協(xié)商等問(wèn)題。在開(kāi)發(fā)環(huán)境中，ProblemDetails響應(yīng)將包含完整的異常堆棧跟蹤，而在生產(chǎn)環(huán)境中，它將僅顯示一般錯(cuò)誤消息。

ProblemDetails是返回HTTP響應(yīng)中錯(cuò)誤的機(jī)器可讀詳細(xì)信息的行業(yè)標(biāo)準(zhǔn)方法。這是從ASP.NET Core 3.x（在某種程度上在2.2版中）的Web API返回錯(cuò)誤消息的普遍支持的方法。

我們將從在靜態(tài)幫助器類中定義UseCustomErrors函數(shù)開(kāi)始。該幫助類將一個(gè)生成響應(yīng)的中間件添加到IApplicationBuilder方法擴(kuò)展中。在開(kāi)發(fā)環(huán)境中，它最終會(huì)調(diào)用WriteResponse方法，并且設(shè)置includeDetails: true。在其他環(huán)境中，includeDetails`設(shè)置為false。

using System; using System.Diagnostics; using System.Text.Json; using System.Threading.Tasks; using Microsoft.AspNetCore.Builder; using Microsoft.AspNetCore.Diagnostics; using Microsoft.AspNetCore.Hosting; using Microsoft.AspNetCore.Http; using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Hosting;public static class CustomErrorHandlerHelper {public static void UseCustomErrors(this IApplicationBuilder app, IHostEnvironment environment){if (environment.IsDevelopment()){app.Use(WriteDevelopmentResponse);}else{app.Use(WriteProductionResponse);}}private static Task WriteDevelopmentResponse(HttpContext httpContext, Func<Task> next)=> WriteResponse(httpContext, includeDetails: true);private static Task WriteProductionResponse(HttpContext httpContext, Func<Task> next)=> WriteResponse(httpContext, includeDetails: false);private static async Task WriteResponse(HttpContext httpContext, bool includeDetails){// .. to implement} }

剩下的就是實(shí)現(xiàn)WriteResponse方法來(lái)生成我們的響應(yīng)的功能。這將從ExceptionHandlerMiddleware（通過(guò)IExceptionHandlerFeature）中檢索異常，并構(gòu)建一個(gè)包含要顯示的詳細(xì)信息的ProblemDetails對(duì)象。然后，它使用System.Text.Json序列化程序?qū)?duì)象寫入Response流。

private static async Task WriteResponse(HttpContext httpContext, bool includeDetails) {// Try and retrieve the error from the ExceptionHandler middlewarevar exceptionDetails = httpContext.Features.Get<IExceptionHandlerFeature>();var ex = exceptionDetails?.Error;// Should always exist, but best to be safe!if (ex != null){// ProblemDetails has it's own content typehttpContext.Response.ContentType = "application/problem+json";// Get the details to display, depending on whether we want to expose the raw exceptionvar title = includeDetails ? "An error occured: " + ex.Message : "An error occured";var details = includeDetails ? ex.ToString() : null;var problem = new ProblemDetails{Status = 500,Title = title,Detail = details};// This is often very handy information for tracing the specific requestvar traceId = Activity.Current?.Id ?? httpContext?.TraceIdentifier;if (traceId != null){problem.Extensions["traceId"] = traceId;}//Serialize the problem details object to the Response as JSON (using System.Text.Json)var stream = httpContext.Response.Body;await JsonSerializer.SerializeAsync(stream, problem);} }

您可以在序列化ProblemDetails之前記錄從HttpContext中檢索的自己喜歡的任何其他值。

請(qǐng)注意，在調(diào)用異常處理程序方法之前，ExceptionHandlerMiddleware會(huì)?清除路由值，以使這些值不可用。

如果您的應(yīng)用程序現(xiàn)在在Development環(huán)境中引發(fā)異常，則您將在響應(yīng)中獲取作為JSON返回的完整異常：

開(kāi)發(fā)中的ProblemDetails響應(yīng)

在生產(chǎn)環(huán)境中，您仍然會(huì)得到ProblemDetails響應(yīng)，但是省略了詳細(xì)信息：

生產(chǎn)中的ProblemDetails響應(yīng)

與MVC /重新執(zhí)行路徑方法相比，此方法顯然具有一些局限性，即您不容易獲得模型綁定，內(nèi)容協(xié)商，簡(jiǎn)單的序列化或本地化（取決于您的方法）。

如果您需要其中任何一個(gè)（例如，也許您使用PascalCase而不是camelCase從MVC進(jìn)行序列化），那么使用此方法可能比其價(jià)值更麻煩。如果是這樣，那么所描述的Controller方法可能是明智的選擇。

如果您不關(guān)心這些，那么本文中顯示的簡(jiǎn)單處理程序方法可能是更好的選擇。無(wú)論哪種方式，都不要嘗試實(shí)現(xiàn)自己的版本ExceptionHandlerMiddleware-使用可用的擴(kuò)展點(diǎn)！????

總結(jié)

在這篇文章中，我描述了Razor Pages和Web API的默認(rèn)異常處理中間件方法。我著重指出了默認(rèn)Web API模板配置的問(wèn)題，尤其是在客戶端期望有效JSON的情況下，即使出現(xiàn)錯(cuò)誤也是如此。

然后，我從官方文檔中展示了建議的方法，該方法使用MVC控制器為API 生成ProblemDetails響應(yīng)。這種方法效果很好，除非問(wèn)題出在您的MVC配置本身上，否則嘗試執(zhí)行ErrorController將會(huì)失敗。

作為替代方案，我展示了如何使用ExceptionHandlerMiddleware為生成響應(yīng)提供定制的異常處理功能。我最后展示了一個(gè)示例處理程序，該處理程序?qū)roblemDetails對(duì)象序列化為JSON，包括Development環(huán)境中的詳細(xì)信息，并在其他環(huán)境中將其排除在外。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的如何创建一个自定义的`ErrorHandlerMiddleware`方法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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