【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<WeatherForecast> 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<MyExceptionMiddleware>();

来看看效果：

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

管道的添加顺序决定了它的执行顺序，所以如果您想扩大异常捕获的范围，可以将该管道放置在 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<Task> 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，很有可能出现拦截结果被覆盖的情况。

最后，偷偷说一句：创作不易，点个推荐吧.....

posted @ 2020-03-09 18:21 句幽阅读(5771) 评论(17) 编辑收藏举报

刷新页面返回顶部

句幽