知行合一|
收藏闪存小组博问

hiwwwk

园龄：5年1个月粉丝：4关注：12

📂.NET Core开发实战
🔖.net core
2022-02-09 00:02阅读: 95评论: 0推荐: 0

22 | 异常处理中间件：区分真异常与逻辑异常

处理异常的方式

  • 异常处理页
  • 异常处理匿名委托
  • IExceptionFilter
  • ExceptionFilterAttribute

示例


新建Web程序👉选择API模板
在Controllers文件夹👉WeatherForecastController类👉Get方法首行抛出一个异常

public IEnumerable<WeatherForecast> Get()
{
    throw new Exception("throw a exception");
	// ...
}

启动程序：image.png
这个页面是在Configure方法中配置的：如果是开发环境就会使用开发环境异常页

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

这样的错误页我们在生产环境是需要关闭掉的。

异常处理页

可以通过定义一个错误页来承载我们的错误信息。
在在Configure方法中配置：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    //if (env.IsDevelopment())
    //{
    //    app.UseDeveloperExceptionPage();
    //}
    app.UseExceptionHandler("/error");
    // ...
}

右键项目新建文件夹Exceptions👉新建IKnownException接口

namespace ExceptionDemo.Exceptions
{
    public interface IKnownException
    {
        public string Message { get; }
        public int ErrorCode { get; }
        public object[] ErrorData { get; }
    }
}

新建KnownException类，对IKnownException接口的默认实现

namespace ExceptionDemo.Exceptions
{
    public class KnownException : IKnownException
    {
        public string Message { get; private set; }

        public int ErrorCode { get; private set; }

        public object[] ErrorData { get; private set; }

        public readonly static IKnownException UnKnown = new KnownException { ErrorCode = 9999, Message = "未知错误" };

        public static IKnownException FromKnownException(IKnownException knownException)
        {
            return new KnownException { Message = knownException.Message, ErrorCode = knownException.ErrorCode, ErrorData = knownException.ErrorData };
        }
    }
}

这里使用FromKnownException静态方法,用于全局控制赋值时的特殊处理。
为什么会需要我们去定义这样一个类型呢？是因为通常情况下，我们系统里面的异常和业务逻辑的异常是不同的。业务逻辑异常上比如说输入的参数，订单的状态不符合条件，当前账户余额不足等。我们有两种处理方式，一种处理方式就是对不同的逻辑输出不同的业务对象，还有一种就是对业务逻辑异常直接输出，用异常来承载我们逻辑的特殊分支。这个时候我们就需要识别出来哪些是我们的业务异常，哪些是我们不确定的异常（比如说网络异常，数据库连接断了）。


Controllers文件夹👉新建ErrorController类

using ExceptionDemo.Exceptions;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

namespace ExceptionDemo.Controllers
{
    public class ErrorController : Controller
    {
        [Route("/error")]
        public IActionResult Index() 
        {
            // 获取异常
            var exceptionHandlerPathFeature = HttpContext.Features.Get<IExceptionHandlerPathFeature>();
            var ex = exceptionHandlerPathFeature?.Error;
            // 尝试将异常转换为已知的异常
            var knownException = ex as IKnownException;           
            if (knownException == null)
            {
                // 如果不是已知的异常，我们就不应该把错误异常完整的输出给客户端
                var logger = HttpContext.RequestServices.GetService<ILogger<ErrorController>>();
                logger.LogError(ex, ex.Message);
                knownException = KnownException.UnKnown;
            }
            else
            {
                // 是已知的异常
                knownException = KnownException.FromKnownException(knownException);
            }
            return View(knownException);
        }
    }
}

右键项目👉新建文件夹Views👉新建文件夹Error👉新建文件Index.cshtml

@model ExceptionDemo.Exceptions.IKnownException
@{
    ViewData["Title"] = "Index";
}

<h1>错误信息</h1>
<div>
    ErrorCode : <label>@Model.ErrorCode</label>
</div>
<div>
    Message : <label>@Model.Message</label>
</div>

Startup类👉ConfigureServices方法

public void ConfigureServices(IServiceCollection services)
{
    //services.AddControllers();
    services.AddControllersWithViews();
}

执行程序：image.png
这个时候未知的错误就会显示出来，而具体的错误会通过logger日志输出出来。

异常处理匿名委托

就是把上面那段逻辑直接定义在我们注册的地方

public void Configure(IApplicationBuilder app, IWebHostEnvironment env,ILoggerFactory loggerFactory)
{
    //if (env.IsDevelopment())
    //{
    //    app.UseDeveloperExceptionPage();
    //}

    //app.UseExceptionHandler("/error");

    app.UseExceptionHandler(error =>
    {
        error.Run(async context =>
        {
            var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
            var knownException = exceptionHandlerPathFeature.Error as IKnownException;
            if (knownException == null)
            {
                var logger = loggerFactory.CreateLogger("Api.Exception");
                logger.LogError(exceptionHandlerPathFeature.Error, exceptionHandlerPathFeature.Error.Message);
                knownException = KnownException.UnKnown;
                // 将错误Http响应码设置为500
                context.Response.StatusCode = StatusCodes.Status500InternalServerError;
            }
            else
            {
                // 是已知的异常
                knownException = KnownException.FromKnownException(knownException);
                // 将Http响应码设置为200
                context.Response.StatusCode = StatusCodes.Status200OK;
            }
            var jsonOptions = context.RequestServices.GetService<IOptions<JsonOptions>>();
            context.Response.ContentType = "application/json;charset=utf-8";
            await context.Response.WriteAsync(JsonSerializer.Serialize(knownException, jsonOptions.Value.JsonSerializerOptions));
        });
    });  
    // ...
}

为什么对于未知的异常要输出 Http 500，而对于业务逻辑的异常，建议输出 Http 200？
因为监控系统实际上会对 Http 的响应码进行识别，当监控系统识别到 Http 响应是 500 的比例比较高的情况下，会认为系统的可用性有问题，这个时候告警系统就会发出警告
对于已知的业务逻辑的这种正常的识别的话，用正常的 Http 200 来处理是一个正常的行为，这样就可以让监控系统更好的工作，正确的识别出系统的一些未知的错误信息，错误的告警，让告警系统更加的灵敏，也避免了业务逻辑的异常干扰告警系统

通过异常过滤器的方式

这种方式实际上是作用在 MVC 的整个框架的体系下面的，它并不是在中间件的最早期发生作用的，它是在 MVC 的整个生命周期里面发生作用，也就是说它只能工作在 MVC Web API 的请求周期里面
Exceptions文件夹👉新建MyExceptionFilter类

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

namespace ExceptionDemo.Exceptions
{
    public class MyExceptionFilter : IExceptionFilter
    {
        public void OnException(ExceptionContext context)
        {
            IKnownException knownException = context.Exception as IKnownException;
            if (knownException == null)
            {
                var logger = context.HttpContext.RequestServices.GetService<ILogger<MyExceptionFilterAttribute>>();
                logger.LogError(context.Exception, context.Exception.Message);
                knownException = KnownException.UnKnown;
                context.HttpContext.Response.StatusCode = StatusCodes.Status500InternalServerError;
            }
            else
            {
                knownException = KnownException.FromKnownException(knownException);
                context.HttpContext.Response.StatusCode = StatusCodes.Status200OK;
            }
            context.Result = new JsonResult(knownException)
            {
                ContentType = "application/json; charset=utf-8"
            };
        }
    }
}

处理的逻辑也与之前相同
ConfigureServices方法注册Filters

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc(mvcOptions =>
    {
        mvcOptions.Filters.Add<MyExceptionFilter>();
    }).AddJsonOptions(jsonOptions =>
    {
        jsonOptions.JsonSerializerOptions.Encoder = System.Text.Encodings.Web.JavaScriptEncoder.UnsafeRelaxedJsonEscaping;
    });
}

启动执行:image.png
输出与之前的一致，因为这是在 Controller 里面输出了错误
如果在 MVC 的中间件之前输出错误的话，它是没办法处理的
这个场景一般情况下是指需要对 Controller 进行特殊的异常处理，而对于中间件整体来讲的话，又要用另一种特殊的逻辑来处理的时候，可以用 ExceptionFilter 的方式处理。
这种方式还可以通过 Attribute 的方式
自定义一个 MyExceptionFilterAttribute

using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.Mvc.Filters;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

namespace ExceptionDemo.Exceptions
{
    public class MyExceptionFilterAttribute : ExceptionFilterAttribute
    {
        public override void OnException(ExceptionContext context)
        {
            IKnownException knownException = context.Exception as IKnownException;
            if (knownException == null)
            {
                var logger = context.HttpContext.RequestServices.GetService<ILogger<MyExceptionFilterAttribute>>();
                logger.LogError(context.Exception, context.Exception.Message);
                knownException = KnownException.UnKnown;
                context.HttpContext.Response.StatusCode = StatusCodes.Status500InternalServerError;
            }
            else
            {
                knownException = KnownException.FromKnownException(knownException);
                context.HttpContext.Response.StatusCode = StatusCodes.Status200OK;
            }
            context.Result = new JsonResult(knownException)
            {
                ContentType = "application/json;charset=uft-8"
            };
        }
    }
}

在 Controller 上面标注 MyExceptionFilter

[MyExceptionFilter]
public class WeatherForecastController : ControllerBase

启动运行之后效果相同
这两种方式的效果是对等的，区别在于说可以更细粒度的对异常处理进行控制，可以指定部分的 Controller 或者 Exception，来决定我们的异常处理，也可以在全局注册 ExceptionFilter
当然因为 ExceptionFilterAttribute 也实现了 IExceptionFilter，所以它也可以注册到全局，也可以把它当作全局异常处理的过滤器来使用，Controller 上面也就不需要标记了
注册 Filters

services.AddMvc(mvcOptions =>
{
    //mvcOptions.Filters.Add<MyExceptionFilter>();
    mvcOptions.Filters.Add<MyExceptionFilterAttribute>();
}).AddJsonOptions(jsonoptions =>
{
    jsonoptions.JsonSerializerOptions.Encoder = System.Text.Encodings.Web.JavaScriptEncoder.UnsafeRelaxedJsonEscaping;
});

在 Controller 上面取消标注 MyExceptionFilter

//[MyExceptionFilter]
public class WeatherForecastController : ControllerBase

启动程序，输出结果一致
这个场景对于我们定义一些 API，然后对 API 进行定义我们的异常处理的约定是很有帮助的

总结一下

首先我们需要定义特定的异常类或者接口，我们可以定义抽象类，也可以用接口的方式，例子中是通过接口的方式表示业务逻辑的异常
对于业务逻辑的异常，实际上需要定义全局的错误码
对于未知的异常，应该输出特定的输出信息和错误码，然后记录完整的日志，我们不应该把系统内部的一些比如说异常堆栈这些信息输出给用户
对于已知的业务逻辑的异常，用 Http 200 的方式，对于未知的异常，用 Http 500 的方式，这样可以让监控系统更好的工作
另外一个建议就是尽量记录所有的异常的详细信息，以供后续对日志进行分析，也供监控系统做一些特定的监控警告

本文作者：hiwwwk

本文链接：https://www.cnblogs.com/wwwk/p/15873404.html

版权声明：本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。

posted @   hiwwwk  阅读(95)  评论(0)  编辑  收藏  举报
点击右上角即可分享
微信分享提示
评论
收藏
关注
推荐
深色
回顶
收起