理解ASP.NET?Core?錯誤處理機制(Handle?Errors)
注：本文隸屬于《理解ASP.NET Core》系列文章，請查看置頂博客或點擊此處查看全文目錄
使用中間件進行錯誤處理
開發(fā)人員異常頁
開發(fā)人員異常頁用于顯示未處理的請求異常的詳細信息。當我們通過ASP.NET Core模板創(chuàng)建一個項目時，Startup.Configure方法中會自動生成以下代碼：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
// 添加開發(fā)人員異常頁中間件
app.UseDeveloperExceptionPage();
}
}
需要注意的是，與“異常處理”有關(guān)的中間件，一定要盡早添加，這樣，它可以最大限度的捕獲后續(xù)中間件拋出的未處理異常。
可以看到，當程序運行在開發(fā)環(huán)境中時，才會啟用開發(fā)人員異常頁，這很好理解，因為在生產(chǎn)環(huán)境中，我們不能將異常的詳細信息暴露給用戶，否則，這將會導致一系列安全問題。
現(xiàn)在我們在下方添加如下代碼拋出一個異常：
app.Use((context, next) =>
{
throw new NotImplementedException();
});
當開發(fā)人員異常頁中間件捕獲了該未處理異常時，會展示類似如下的相關(guān)信息：
該異常頁面展示了如下信息：
- 異常消息
- 異常堆棧追蹤（Stack）
- HTTP請求查詢參數(shù)（Query）
- Cookies
- HTTP請求標頭（Headers）
- 路由（Routing），包含了終結(jié)點和路由信息
IDeveloperPageExceptionFilter
當你查看DeveloperExceptionPageMiddleware的源碼時，你會在構(gòu)造函數(shù)中發(fā)現(xiàn)一個入?yún)?，類型?code>IEnumerable<IDeveloperPageExceptionFilter>。通過這個Filter集合，組成一個錯誤處理器管道，按照先注冊先執(zhí)行的原則，順序進行錯誤處理。
下面是DeveloperExceptionPageMiddleware的核心源碼：
public class DeveloperExceptionPageMiddleware
{
public DeveloperExceptionPageMiddleware(
RequestDelegate next,
IOptions<DeveloperExceptionPageOptions> options,
ILoggerFactory loggerFactory,
IWebHostEnvironment hostingEnvironment,
DiagnosticSource diagnosticSource,
IEnumerable<IDeveloperPageExceptionFilter> filters)
{
// ...
// 將 DisplayException 放置在管道最底部
// DisplayException 就用于向響應(yīng)中寫入我們上面見到的異常頁
_exceptionHandler = DisplayException;
foreach (var filter in filters.Reverse())
{
var nextFilter = _exceptionHandler;
_exceptionHandler = errorContext => filter.HandleExceptionAsync(errorContext, nextFilter);
}
}
public async Task Invoke(HttpContext context)
{
try
{
await _next(context);
}
catch (Exception ex)
{
// 響應(yīng)已經(jīng)啟動，則跳過處理，直接上拋
if (context.Response.HasStarted)
{
throw;
}
try
{
context.Response.Clear();
context.Response.StatusCode = 500;
// 錯誤處理
await _exceptionHandler(new ErrorContext(context, ex));
// ...
// 錯誤已成功處理
return;
}
catch (Exception ex2) { }
// 若處理過程中拋出了新的異常ex2，則重新引發(fā)原始異常ex
throw;
}
}
}
這也就說明，如果我們想要自定義開發(fā)者異常頁，那我們可以通過實現(xiàn)IDeveloperPageExceptionFilter接口來達到目的。
先看一下IDeveloperPageExceptionFilter接口定義：
public interface IDeveloperPageExceptionFilter
{
Task HandleExceptionAsync(ErrorContext errorContext, Func<ErrorContext, Task> next);
}
public class ErrorContext
{
public ErrorContext(HttpContext httpContext, Exception exception)
{
HttpContext = httpContext ?? throw new ArgumentNullException(nameof(httpContext));
Exception = exception ?? throw new ArgumentNullException(nameof(exception));
}
public HttpContext HttpContext { get; }
public Exception Exception { get; }
}
HandleExceptionAsync方法除了錯誤上下文信息外，還包含了一個Func<ErrorContext, Task> next，這是干嘛的呢？其實，前面我們已經(jīng)提到了，IDeveloperPageExceptionFilter的所有實現(xiàn)，會組成一個管道，當錯誤需要在管道中的后續(xù)處理器作進一步處理時，就是通過這個next傳遞錯誤的，所以，當需要傳遞錯誤時，一定要記得調(diào)用next！
不廢話了，趕緊實現(xiàn)一個看看效果吧：
public class MyDeveloperPageExceptionFilter : IDeveloperPageExceptionFilter
{
public Task HandleExceptionAsync(ErrorContext errorContext, Func<ErrorContext, Task> next)
{
errorContext.HttpContext.Response.WriteAsync($"MyDeveloperPageExceptionFilter: {errorContext.Exception}");
// 我們不調(diào)用 next，這樣就不會執(zhí)行 DisplayException
return Task.CompletedTask;
}
}
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<IDeveloperPageExceptionFilter, MyDeveloperPageExceptionFilter>();
}
當拋出一個異常，你會看到類似如下的頁面：
異常處理程序
上面介紹了開發(fā)環(huán)境中的異常處理，現(xiàn)在我們來看一下生產(chǎn)環(huán)境中的異常處理，通過調(diào)用UseExceptionHandler擴展方法注冊中間件ExceptionHandlerMiddleware。
該異常處理程序：
- 可以捕獲后續(xù)中間件未處理的異常
- 若無異?；騂TTP響應(yīng)已經(jīng)啟動（
Response.HasStarted == true），則不做任何處理 - 不會改變URL中的路徑
默認情況下，會生成類似如下的模板：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
// 添加異常處理程序
app.UseExceptionHandler("/Home/Error");
}
}
通過lambda提供異常處理程序
我們可以通過lambda向UseExceptionHandler中提供一個異常處理邏輯：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseExceptionHandler(errorApp =>
{
var loggerFactory = errorApp.ApplicationServices.GetRequiredService<ILoggerFactory>();
var logger = loggerFactory.CreateLogger("ExceptionHandlerWithLambda");
errorApp.Run(async context =>
{
// 這里可以自定義 http response 內(nèi)容，以下僅是示例
var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
logger.LogError($"Exception Handled：{exceptionHandlerPathFeature.Error}");
var statusCode = StatusCodes.Status500InternalServerError;
var message = exceptionHandlerPathFeature.Error.Message;
if (exceptionHandlerPathFeature.Error is NotImplementedException)
{
message = "俺未實現(xiàn)";
statusCode = StatusCodes.Status501NotImplemented;
}
context.Response.StatusCode = statusCode;
context.Response.ContentType = "application/json";
await context.Response.WriteAsJsonAsync(new
{
Message = message,
Success = false,
});
});
});
}
可以看到，當捕獲到異常時，可以通過HttpContext.Features，并指定類型IExceptionHandlerPathFeature或IExceptionHandlerFeature（前者繼承自后者），來獲取到異常信息。
public interface IExceptionHandlerFeature
{
// 異常信息
Exception Error { get; }
}
public interface IExceptionHandlerPathFeature : IExceptionHandlerFeature
{
// 未被轉(zhuǎn)義的http請求資源路徑
string Path { get; }
}
再提醒一遍，千萬不要將敏感的錯誤信息暴露給客戶端。
異常處理程序頁
除了使用lambda外，我們還可以指定一個路徑，指向一個備用管道進行異常處理，這個備用管道對于MVC來說，一般是Controller中的Action，例如MVC模板默認的/Home/Error：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseExceptionHandler("/Home/Error");
}
public class HomeController : Controller
{
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
當捕獲到異常時，你會看到類似如下的頁面：
你可以在ActionError中自定義錯誤處理邏輯，就像lambda一樣。
需要注意的是，不要隨意對Error添加[HttpGet]、[HttpPost]等限定Http請求方法的特性。一旦你加上了[HttpGet]，那么該方法只能處理Get請求的異常。
不過，如果你就是打算將不同方法的Http請求分別進行處理，你可以類似如下進行處理：
public class HomeController : Controller
{
// 處理Get請求的異常
[HttpGet("[controller]/error")]
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult GetError()
{
_logger.LogInformation("Get Exception Handled");
return View("Error", new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
// 處理Post請求的異常
[HttpPost("[controller]/error")]
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult PostError()
{
_logger.LogInformation("Post Exception Handled");
return View("Error", new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
另外，還需要提醒一下，如果在請求備用管道（如示例中的Error）時也報錯了，無論是Http請求管道中的中間件報錯，還是Error里面報錯，此時ExceptionHandlerMiddleware均會重新引發(fā)原始異常，而不是向外拋出備用管道的異常。
一般異常處理程序頁是面向所有用戶的，所以請保證它可以匿名訪問。
下面一塊看一下ExceptionHandlerMiddleware吧：
public class ExceptionHandlerMiddleware
{
public ExceptionHandlerMiddleware(
RequestDelegate next,
ILoggerFactory loggerFactory,
IOptions<ExceptionHandlerOptions> options,
DiagnosticListener diagnosticListener)
{
// 要么手動指定一個異常處理器（如通過lambda）
// 要么提供一個資源路徑，重新發(fā)送給后續(xù)中間件，進行異常處理
if (_options.ExceptionHandler == null)
{
if (_options.ExceptionHandlingPath == null)
{
throw new InvalidOperationException(Resources.ExceptionHandlerOptions_NotConfiguredCorrectly);
}
else
{
_options.ExceptionHandler = _next;
}
}
}
public Task Invoke(HttpContext context)
{
ExceptionDispatchInfo edi;
try
{
var task = _next(context);
if (!task.IsCompletedSuccessfully)
{
return Awaited(this, context, task);
}
return Task.CompletedTask;
}
catch (Exception exception)
{
edi = ExceptionDispatchInfo.Capture(exception);
}
// 同步完成并拋出異常時，進行處理
return HandleException(context, edi);
static async Task Awaited(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)
{
ExceptionDispatchInfo edi = null;
try
{
await task;
}
catch (Exception exception)
{
edi = ExceptionDispatchInfo.Capture(exception);
}
if (edi != null)
{
// 異步完成并拋出異常時，進行處理
await middleware.HandleException(context, edi);
}
}
}
private async Task HandleException(HttpContext context, ExceptionDispatchInfo edi)
{
// 響應(yīng)已經(jīng)啟動，則跳過處理，直接上拋
if (context.Response.HasStarted)
{
edi.Throw();
}
PathString originalPath = context.Request.Path;
if (_options.ExceptionHandlingPath.HasValue)
{
context.Request.Path = _options.ExceptionHandlingPath;
}
try
{
ClearHttpContext(context);
// 將 exceptionHandlerFeature 存入 context.Features
var exceptionHandlerFeature = new ExceptionHandlerFeature()
{
Error = edi.SourceException,
Path = originalPath.Value,
};
context.Features.Set<IExceptionHandlerFeature>(exceptionHandlerFeature);
context.Features.Set<IExceptionHandlerPathFeature>(exceptionHandlerFeature);
context.Response.StatusCode = StatusCodes.Status500InternalServerError;
context.Response.OnStarting(_clearCacheHeadersDelegate, context.Response);
// 處理異常
await _options.ExceptionHandler(context);
if (context.Response.StatusCode != StatusCodes.Status404NotFound || _options.AllowStatusCode404Response)
{
return;
}
}
catch (Exception ex2) { }
finally
{
// 還原請求路徑，保證瀏覽器中的Url不變
context.Request.Path = originalPath;
}
// 如果異常未被處理，則重新引發(fā)原始異常
edi.Throw();
}
}
無響應(yīng)正文的Http錯誤狀態(tài)碼處理
默認情況下，當ASP.NET Core遇到?jīng)]有正文的400-599Http錯誤狀態(tài)碼時，不會為其提供頁面，而是返回狀態(tài)碼和空響應(yīng)正文。可是，為了良好的用戶體驗，一般我們會對常見的錯誤狀態(tài)碼（404）提供友好的頁面，如gitee404
請注意，本節(jié)所涉及到的中間件與上兩節(jié)所講解的錯誤異常處理中間件不沖突，可以同時使用。確切的說，本節(jié)并不是處理異常，只是為了提升用戶體驗。
UseStatusCodePages
我們可以通過StatusCodePagesMiddleware中間件實現(xiàn)該功能：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
app.UseDeveloperExceptionPage();
// 添加 StatusCodePagesMiddleware 中間件
app.UseStatusCodePages();
// ...請求處理中間件
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
});
}
注意，一定要在異常處理中間件之后，請求處理中間件之前調(diào)用UseStatusCodePages。
現(xiàn)在，你可以請求一個不存在的路徑，例如Home/Index2，你會在瀏覽器中看到如下輸出：
Status Code: 404; Not Found?
UseStatusCodePages也提供了重載，允許我們自定義響應(yīng)內(nèi)容類型和正文內(nèi)容，如：
// 使用占位符 {0} 來填充Http狀態(tài)碼
app.UseStatusCodePages("text/plain", "Status code is: {0}");
瀏覽器輸出為：
Status code is: 404
同樣地，我們也可以通過向UseStatusCodePages傳入lambda表達式進行處理：
app.UseStatusCodePages(async context =>
{
context.HttpContext.Response.ContentType = "text/plain";
await context.HttpContext.Response.WriteAsync(
$"Status code is: {context.HttpContext.Response.StatusCode}");
});
介紹了那么多，你也看到了，事實上UseStatusCodePages效果并不好，所以我們在生產(chǎn)環(huán)境一般是不會用這玩意的，那用啥呢？請隨我繼續(xù)往下看。
UseStatusCodePagesWithRedirects
該擴展方法，內(nèi)部實際上是通過調(diào)用UseStatusCodePages并傳入lambda進行實現(xiàn)的，該方法：
- 接收一個Http資源定位字符串。同樣的，會有一個占位符
{0}，用于填充Http狀態(tài)碼 - 向客戶端發(fā)送Http狀態(tài)碼302-已找到
- 然后將客戶端重定向到指定的終結(jié)點，在該終結(jié)點中，可以針對不同錯誤狀態(tài)碼分別進行處理
app.UseStatusCodePagesWithRedirects("/Home/StatusCodeError?code={0}");
public class HomeController : Controller
{
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public IActionResult StatusCodeError(int code)
{
return code switch
{
// 跳轉(zhuǎn)到404頁面
StatusCodes.Status404NotFound => View("404"),
// 跳轉(zhuǎn)到統(tǒng)一展示頁面
_ => View(code),
};
}
}
現(xiàn)在你可以自己試一下。
不知道你有沒有注意：當我們請求一個不存在的路徑時，它的確會跳轉(zhuǎn)到404頁面，但是，Url也變了，變成了/Home/StatusCodeError?code=404，而且，響應(yīng)狀態(tài)碼也變了，變成了200Ok?？梢酝ㄟ^源碼看一下咋回事（我相信，大家看到302其實也都明白了）：
public static IApplicationBuilder UseStatusCodePagesWithRedirects(this IApplicationBuilder app, string locationFormat)
{
// 兩個條件分支都差不多，我們看第二個，容易理解一些
if (locationFormat.StartsWith("~"))
{
locationFormat = locationFormat.Substring(1);
return app.UseStatusCodePages(context =>
{
var location = string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
context.HttpContext.Response.Redirect(context.HttpContext.Request.PathBase + location);
return Task.CompletedTask;
});
}
else
{
return app.UseStatusCodePages(context =>
{
// 格式化資源定位，context.HttpContext.Response.StatusCode 作占位符
var location = string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
// 重定向（302）到設(shè)定的資源
context.HttpContext.Response.Redirect(location);
return Task.CompletedTask;
});
}
}
如果你不想更改原始請求的Url，而且保留原始狀態(tài)碼，那么你應(yīng)該使用接下來要介紹的UseStatusCodePagesWithReExecute。
UseStatusCodePagesWithReExecute
同樣的，該擴展方法，內(nèi)部也是通過調(diào)用UseStatusCodePages并傳入lambda進行實現(xiàn)的，不過該方法：
- 接收1個路徑字符串和和1個查詢字符串。同樣的，會有一個占位符
{0}，用于填充Http狀態(tài)碼 - Url保持不變，并向客戶端返回原始Http狀態(tài)碼
- 執(zhí)行備用管道，用于生成響應(yīng)正文
// 注意，這里要分開寫
app.UseStatusCodePagesWithReExecute("/Home/StatusCodeError", "?code={0}");
具體例子就不再列舉了，用上面的就行了?，F(xiàn)在來看看源碼：
public static IApplicationBuilder UseStatusCodePagesWithReExecute(
this IApplicationBuilder app,
string pathFormat,
string queryFormat = null)
{
return app.UseStatusCodePages(async context =>
{
// 請注意，此時Http響應(yīng)還未啟動
// 格式化資源路徑，context.HttpContext.Response.StatusCode 作占位符
var newPath = new PathString(
string.Format(CultureInfo.InvariantCulture, pathFormat, context.HttpContext.Response.StatusCode));
// 格式化查詢字符串，context.HttpContext.Response.StatusCode 作占位符
var formatedQueryString = queryFormat == null ? null :
string.Format(CultureInfo.InvariantCulture, queryFormat, context.HttpContext.Response.StatusCode);
var newQueryString = queryFormat == null ? QueryString.Empty : new QueryString(formatedQueryString);
var originalPath = context.HttpContext.Request.Path;
var originalQueryString = context.HttpContext.Request.QueryString;
// 將原始請求信息保存下來，以便后續(xù)進行還原
context.HttpContext.Features.Set<IStatusCodeReExecuteFeature>(new StatusCodeReExecuteFeature()
{
OriginalPathBase = context.HttpContext.Request.PathBase.Value,
OriginalPath = originalPath.Value,
OriginalQueryString = originalQueryString.HasValue ? originalQueryString.Value : null,
});
context.HttpContext.SetEndpoint(endpoint: null);
var routeValuesFeature = context.HttpContext.Features.Get<IRouteValuesFeature>();
routeValuesFeature?.RouteValues?.Clear();
// 構(gòu)造新請求
context.HttpContext.Request.Path = newPath;
context.HttpContext.Request.QueryString = newQueryString;
try
{
// 執(zhí)行備用管道，生成響應(yīng)正文
await context.Next(context.HttpContext);
}
finally
{
// 還原原始請求信息
context.HttpContext.Request.QueryString = originalQueryString;
context.HttpContext.Request.Path = originalPath;
context.HttpContext.Features.Set<IStatusCodeReExecuteFeature>(null);
}
});
}
在MVC中，你可以通過給控制器或其中的Action方法添加[SkipStatusCodePages]特性，可以略過StatusCodePagesMiddleware。
使用過濾器進行錯誤處理
除了錯誤處理中間件外，ASP.NET Core 還提供了異常過濾器，用于錯誤處理。
異常過濾器：
- 通過實現(xiàn)接口
IExceptionFilter或IAsyncExceptionFilter來自定義異常過濾器 - 可以捕獲Controller創(chuàng)建時（也就是只捕獲構(gòu)造函數(shù)中拋出的異常）、模型綁定、Action Filter和Action中拋出的未處理異常
- 其他地方拋出的異常不會捕獲
本節(jié)僅介紹異常過濾器，有關(guān)過濾器的詳細內(nèi)容，后續(xù)文章將會介紹
先來看一下這兩個接口：
// 僅具有標記作用，標記其為 mvc 請求管道的過濾器
public interface IFilterMetadata { }
public interface IExceptionFilter : IFilterMetadata
{
// 當拋出異常時，該方法會捕獲
void OnException(ExceptionContext context);
}
public interface IAsyncExceptionFilter : IFilterMetadata
{
// 當拋出異常時，該方法會捕獲
Task OnExceptionAsync(ExceptionContext context);
}
OnException和OnExceptionAsync方法都包含一個類型為ExceptionContext參數(shù)，很顯然，它就是與異常有關(guān)的上下文，我們的異常處理邏輯離不開它。那接著來看一下它的結(jié)構(gòu)吧：
public class ExceptionContext : FilterContext
{
// 捕獲到的未處理異常
public virtual Exception Exception { get; set; }
public virtual ExceptionDispatchInfo? ExceptionDispatchInfo { get; set; }
// 指示異常是否已被處理
// true：表示異常已被處理，異常不會再向上拋出
// false：表示異常未被處理，異常仍會繼續(xù)向上拋出
public virtual bool ExceptionHandled { get; set; }
// 設(shè)置響應(yīng)的 IActionResult
// 如果設(shè)置了結(jié)果，也表示異常已被處理，異常不會再向上拋出
public virtual IActionResult? Result { get; set; }
}
除此之外，ExceptionContext還繼承了FilterContext，而FilterContext又繼承了ActionContext（這也從側(cè)面說明，過濾器是為Action服務(wù)的），也就是說我們也能夠獲取到一些過濾器和Action相關(guān)的信息，看看都有什么吧：
public class ActionContext
{
// Action相關(guān)的信息
public ActionDescriptor ActionDescriptor { get; set; }
// HTTP上下文
public HttpContext HttpContext { get; set; }
// 模型綁定和驗證
public ModelStateDictionary ModelState { get; }
// 路由數(shù)據(jù)
public RouteData RouteData { get; set; }
}
public abstract class FilterContext : ActionContext
{
public virtual IList<IFilterMetadata> Filters { get; }
public bool IsEffectivePolicy<TMetadata>(TMetadata policy) where TMetadata : IFilterMetadata {}
public TMetadata FindEffectivePolicy<TMetadata>() where TMetadata : IFilterMetadata {}
}
更多參數(shù)細節(jié)，我會在專門講過濾器的文章中詳細介紹。
下面，我們就來實現(xiàn)一個自定義的異常處理器：
public class MyExceptionFilterAttribute : ExceptionFilterAttribute
{
private readonly IModelMetadataProvider _modelMetadataProvider;
public MyExceptionFilterAttribute(IModelMetadataProvider modelMetadataProvider)
{
_modelMetadataProvider = modelMetadataProvider;
}
public override void OnException(ExceptionContext context)
{
if (!context.ExceptionHandled)
{
// 此處僅為簡單演示
var exception = context.Exception;
var result = new ViewResult()
{
ViewName = "Error",
ViewData = new ViewDataDictionary(_modelMetadataProvider, context.ModelState)
{
// 記得給 ErrorViewModel 加上 Message 屬性
Model = new ErrorViewModel
{
Message = exception.ToString()
}
}
};
context.Result = result;
// 標記異常已處理
context.ExceptionHandled = true;
}
}
}
接著，找到/Views/Shared/Error.cshtml，展示一下錯誤消息：
@model ErrorViewModel
@{
ViewData["Title"] = "Error";
}
<p>@Model.Message</p>
最后，將服務(wù)MyExceptionFilterAttribute注冊到DI容器：
public void ConfigureServices(IServiceCollection services)
{
services.AddScoped<MyExceptionFilterAttribute>();
services.AddControllersWithViews();
}
現(xiàn)在，我們將該異常處理器加在/Home/Index上，并拋個異常：
public class HomeController : Controller
{
[ServiceFilter(typeof(MyExceptionFilterAttribute))]
public IActionResult Index()
{
throw new Exception("Home Index Error");
return View();
}
}
當請求/Home/Index時，你會得到如下頁面：
錯誤處理中間件 VS 異常過濾器
現(xiàn)在，我們已經(jīng)介紹了兩種錯誤處理的方法——錯誤處理中間件和異常過濾器?，F(xiàn)在來比較一下它們的異同，以及我們何時應(yīng)該選擇哪種處理方式。
錯誤處理中間件：
- 可以捕獲后續(xù)中間件的所有未處理異常
- 擁有
RequestDelegate，操作更加靈活 - 粒度較粗，僅可針對全局進行配置
錯誤處理中間件適合用于處理全局異常。
異常過濾器：
- 僅可捕獲Controller創(chuàng)建時（也就是構(gòu)造函數(shù)中拋出的異常）、模型綁定、Action Filter和Action中拋出的未處理異常，其他地方拋出的異常捕獲不到
- 粒度更小，可以靈活針對Controller或Action配置不同的異常過濾器
異常過濾器非常適合用于捕獲并處理Action中的異常。
在我們的應(yīng)用中，可以同時使用錯誤處理中間件和異常過濾器，只有充分發(fā)揮它們各自的優(yōu)勢，才能處理好程序中的錯誤。
到此這篇關(guān)于理解ASP.NET Core 錯誤處理(Handle Errors) 的文章就介紹到這了,更多相關(guān)ASP.NET Core 錯誤處理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
.Net語言Smobiler開發(fā)之如何在手機上實現(xiàn)表單設(shè)計
這篇文章主要為大家詳細介紹了.Net語言APP開發(fā)平臺，如何在手機上實現(xiàn)表單設(shè)計（Smobiler）,具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-09-09
aspnetpager重寫url(偽靜態(tài))配置實例
這幾天要用到AspNetPager來做偽靜態(tài)分頁，找了些資料并把修改過程記錄下來。2013-04-04
這篇文章主要介紹了asp.net調(diào)試方便的知識點，在CSDN找了一些相關(guān)的解決方法，不敢獨享，供大家相互學習交流之用2013-11-11
基于.NET的FluentValidation數(shù)據(jù)驗證實現(xiàn)
這篇文章主要介紹了基于.NET的FluentValidation數(shù)據(jù)驗證實現(xiàn)，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2020-11-11
asp.net下對于編輯器中的ubb進行替換處理的實現(xiàn)代碼2008-08-08
剛到一家新公司，領(lǐng)導下發(fā)任務(wù)要用cs系統(tǒng)做一個表格折疊顯示，這真是把我難倒了，自己工作6年一直以來都是做BS的系統(tǒng)，于是上網(wǎng)搜了相關(guān)視頻，資料，開始學習起來，下面小編把WinForm中DataGridView折疊控件的知識分享給大家，供大家參考2016-05-05
最近一直在思考如何做一個支持多種數(shù)據(jù)庫的程序，打印了很多的資料，在.NET 2.0中，新增加了DbProviderFactory抽象工廠類，讓數(shù)據(jù)層基類可以實現(xiàn)多種數(shù)據(jù)庫，但在數(shù)據(jù)訪問層中的參數(shù)部分我覺得是個麻煩。2009-07-07
本篇文章主要介紹了ASP.NET 頁面之間傳值的幾種方式，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-01-01
asp.net發(fā)布后web.config中compilation的debug的值true和false區(qū)別點整理
在本篇文章里小編給大家整理的是一篇關(guān)于asp.net發(fā)布后web.config中compilation的debug的值true和false區(qū)別點內(nèi)容，有需要的為朋友們可以參考下。2020-01-01
RadioButtonList綁定圖片及泛型Dictionary應(yīng)用
讀取站點某一目錄的圖片,需要掌握LINQ與泛型Dictionary<TKey,TValue>的使用,本文將介紹RadioButtonList綁定圖片的實現(xiàn)，感興趣的朋友可以了解下，或許對你有所幫助2013-02-02