【5min+】AspNet Core中的全局异常处理
系列介绍
【五分钟的dotnet】是一个利用您的碎片化时间来学习和丰富.net知识的博文系列。它所包含了.net体系中可能会涉及到的方方面面，比如C#的小细节，AspnetCore，微服务中的.net知识等等。
5min+不是超过5分钟的意思，"+"是知识的增加。so，它是让您花费5分钟以下的时间来提升您的知识储备量。

正文
其实一说到AspNet Core里面的全局异常，其实大家都不会陌生。因为这玩意儿用的非常频繁，好的异常处理方案能够帮助开发者更快速的定位问题，也能够给用户更好的用户体验。

比如，当您访问到一个网页，突然，它喵的报错了！您没有看错，它报错了！！！然后显示了这样的一个错误页面：

请问，此刻电脑屏幕前的您会什么感受。（真想掏出那传说中的95级史诗巨剑！）

但是，假若我们稍微处理一下这个异常，比如用咱们腾讯爸爸的手段，换个皮肤：

用户马上就会想：“哎呀，错误就错误嘛，孰能无过，程序员锅锅也挺辛苦的。”

由此可见！！！全局异常的捕获和处理是有多么的重要。

AspNet Core 中的全局处理
IAsyncExceptionFilter
那么在AspNet Core中我们该如何捕获和处理异常呢？ 可能很多同学都知道：IExceptionFilter 。 这个过滤器应该算是AspNet里面的老牌过滤器了，从很早就延续至今，它允许咱们捕获AspNet Core的控制器中的错误。不过，对于使用 IExceptionFilter，其实我更建议您考虑它的异步版本： IAsyncExceptionFilter。（别问为什么，问就是爱的供养）。

那么我们来看看该过滤器是怎么使用的呢？ 下面以 IAsyncExceptionFilter 为例，对于同步版本其实也是一样的：

public class MyCustomerExceptionFilter : IAsyncExceptionFilter
{

public Task OnExceptionAsync(ExceptionContext context)
{
    if (context.ExceptionHandled == false)
    {
        string msg = context.Exception.Message;
        context.Result = new ContentResult
        {
            Content = msg,
            StatusCode = StatusCodes.Status200OK,
            ContentType = "text/html;charset=utf-8"
        };
    }
    context.ExceptionHandled = true; //异常已处理了

    return Task.CompletedTask;
}

}
上面咱们新建了一个自定义的异常过滤器，代码很简单，就是报错了之后依旧让Http返回状态码为200的结果。并且将错误信息返回到客户端。

然后还需要在 Startup.cs 中，告诉 MVC 咱们新加的这个过滤器：

services.AddControllers(options => options.Filters.Add(new MyCustomerExceptionFilter()));
然后就完了，是不是so easy？ 来看看结果：

[HttpGet]
public IEnumerable Get()
{

throw new Exception("has error!");

}

如果不增加该过滤器，我们将得到Http状态码为500的响应。这对于某些不致命的意外操作来说，有点杀鸡用牛刀的感觉，对于前端用户来说也不是很友好（明明输错了一个字符，就直接被告知网站崩溃，并且出现乔殿下）。

而咱们捕获了异常，进行特殊处理之后就显得很友好了。（返回200，并且告诉用户输错了某字符等）。

在上面的代码中，您会看到有一行 context.ExceptionHandled = true;。注意！！！ 这很关键，当您处理完异常之后，请记得将此属性更改为true，表明异常已经处理过了。如果不更改的话，嘿嘿🤪。会有什么结果呢？ 请看下面↓

中间件处理异常
由于AspNet Core管道的层层传递的特点，咱们就有机会在管道中实现全局异常捕获。 新建一个中间件来试试吧：

public class MyExceptionMiddleware
{

private readonly RequestDelegate _next;
public MyExceptionMiddleware(RequestDelegate next)
{
    _next = next;
}
public async Task Invoke(HttpContext httpContext)
{
    try
    {
        await _next(httpContext);
    }
    catch (Exception ex)
    {
        httpContext.Response.ContentType = "application/problem+json";

        var title = "An error occured: " + ex.Message;
        var details = ex.ToString();

        var problem = new ProblemDetails
        {
            Status = 200,
            Title = title,
            Detail = details
        };

        //Serialize the problem details object to the Response as JSON (using System.Text.Json)
        var stream = httpContext.Response.Body;
        await JsonSerializer.SerializeAsync(stream, problem);
    }
}

}
然后在 Startup.cs 中，注册管道：

app.UseMiddleware();
来看看效果：

还是原来的味道，还是熟悉的配方，爽歪歪！

管道的添加顺序决定了它的执行顺序，所以如果您想扩大异常捕获的范围，可以将该管道放置在 Configure 的第一行。 但是！！ 您会发现，这个默认的AspNet Core项目不是已经在第一行弄了一个异常处理么？ 我*&&……&。

if (env.IsDevelopment())
{

app.UseDeveloperExceptionPage();

}
else
{

app.UseExceptionHandler("/Error");

}
这行代码大家在初始化新AspNetCore项目时就会看到，也有可能您只有上半段，这和模板有关系。不过这都没有关系，它的作用就是捕获和处理异常而已。关于 UseDeveloperExceptionPage 该扩展咱们就不多说了，它的意思是：对于开发模式，一旦报错就会跳转到错误堆栈页面。 而第二个 UseExceptionHandler 就很有意思了，从它命名就可以看出，它肯定是个错误拦截程序。那么它和咱们自定义的异常处理管道有什么区别呢？

“不指定肯定有个默认吧！” 是的，它就是默认的错误处理。所以，它其实也是一个中间件，它的真身叫做 ExceptionHandlerMiddleware。在使用 UseExceptionHandler 方法时，我们可以选填各种参数。比如上方的代码，填入了 "/Error" 参数，表示当产生异常的时候，将定向到对应路径，此处就定位的是: "http://localhost:5001/Error" 。当然您也可以随意指定页面，比如 漂亮的乔殿下页面。😝

还有指定 ExceptionHandlerOptions 参数的方法，该参数是ExceptionHandlerMiddleware中间件的重要参数：

参数名 说明
ExceptionHandlingPath 重定向的路径，比如刚才的 ""/Error"" 实际上就是指定的该参数
ExceptionHandler 错误拦截处理程序
ExceptionHandler 允许我们在 ExceptionHandlerMiddleware 内部指定咱们自有的异常处理逻辑。而该参数的类型为 RequestDelegate，是否很眼熟，没错，管道处理！因此UseExceptionHandler 提供了一个简便的写法，可以让我们在ExceptionHandlerMiddleware 中又新建自定义的错误拦截管道来作为处理程序：

//in Configure()
app.UseExceptionHandler(appbuilder => appbuilder.Use(ExceptionHandlerDemo));

//该内容会在AspNetCore的管道返回结果至ExceptionHandlerMiddleware时，如果中间件捕获到了异常时调用
private async Task ExceptionHandlerDemo(HttpContext httpContext, Func next)
{

//该信息由ExceptionHandlerMiddleware中间件提供，里面包含了ExceptionHandlerMiddleware中间件捕获到的异常信息。
var exceptionDetails = httpContext.Features.Get<IExceptionHandlerFeature>();
var ex = exceptionDetails?.Error;

if (ex != null)
{
    httpContext.Response.ContentType = "application/problem+json";

    var title = "An error occured: " + ex.Message;
    var details = ex.ToString();

    var problem = new ProblemDetails
    {
        Status = 500,
        Title = title,
        Detail = details
    };

    var stream = httpContext.Response.Body;
    await JsonSerializer.SerializeAsync(stream, problem);
}

}
管道 VS 过滤器
那么上面两个方法有什么区别呢？ 回答：拦截范围。

IExceptionFilter 作为MVC中间件之间的内容，它需要MVC在发现错误之后将错误信息提交给它处理，因此它的错误处理范围仅限于MVC中间件。所以，假如我们需要捕获MVC中间件之前的一些错误，其实是捕获不到的。 而对于ExceptionHandlerMiddleware中间件来说就很简单了，它作为第一个中间件，凡是在它之后的所有错误它都能够捕获得到。

那么这么看来是否IExceptionFilter就毫无用武之地了呢？ 非也，假如您想在MVC发生异常时快速捕获和处理，使用过滤器其实是您不错得选择，如果您仅仅关心控制器之间的异常，那么过滤器也是很好的选择。

还记得刚开始我们在过滤器中说过的这一行代码吗：context.ExceptionHandled = true;。如果在IExceptionFilter中将异常标记为已经处理之后，则第一道异常处理中间件就认为没有错误了，不会进入到处理逻辑中。所以，如果咱们不把该属性改为 true，很有可能出现拦截结果被覆盖的情况。

原文地址https://www.cnblogs.com/uoyo/p/12450205.html