Asp.Net Web API exception handling experience summary

In the previous tutorial, I introduced to you the development and use of Filter in Web API. When talking about ExceptionFilter, there was a pitfall: ExceptionFilter can only intercept and process events that occur during Action execution. Exception, if an exception occurs outside of the Action execution process, ExceptionFilter is powerless.

These exceptions include:

1. Exceptions that occur in the Controller construction method

2. Exceptions that occur in MessageHandlers

3. Exceptions that occur during the routing process Exceptions

　4. Exceptions that occur during the serialization/deserialization process of Body

It can be seen that ExceptionFilter can only solve the exceptions that occur after the ApiControler is successfully instantiated and during the execution of Action. Exceptions; in order to solve this problem, in addition to ExceptionFilter, two extension points for exception recording and processing are introduced in the WEB API:

IExceptionLogger and IExceptionHandler.

and these two extensions are registered and managed as a pipeline component for the web API, and they have different division of labor:

iexceptionLogger as an abnormal log record component. Recording runs through the entire Web API life cycle. In the Web API framework, any uncaught/handled exception in any request cycle will first enter the exception logging pipeline for exception Log recording. In the Web API Multiple IExceptionLogger instances can be registered to be responsible for different exception handling.

                                                                                                                                                              IExceptionHandler, as an exception handling component, is responsible for the processing after the exception occurs. It is at the end of the exception processing pipeline. When the IExceptionLogger component completes a recording and there is no relevant ExceptoinFilter to handle the exception, it will finally Call ExceptionHandler for exception handling. In Web API, there is only one ExceptionHandler for exception handling.

In the Web API framework, two base classes are given: ExceptionLogger and ExceptionHandler. When using the ExceptionLogger base class, it provides the ShouldLog virtual method. This method is called in the base class and its function is to avoid The same exception is repeatedly recorded by the same ExceptionLogger instance (for example, when the exception is thrown again in the subsequent pipeline, or the same ExceptionLogger object is accidentally registered twice, there is a possibility of repeated recording). We can also override the ShouldLog method. Add our own exception record judgment logic to make different ExceptionLogger calls for different scenarios. If you are interested, you can decompile the ExceptionLogger base class and take a look. It uses the display interface implementation, which is a very interesting technique. Let's look at an example of using ExceptionLogger:

    public class ErroLogger : ExceptionLogger
    {        public  async Task LogAsync(ExceptionLoggerContext context, CancellationToken cancellationToken)
        {            var sb = new StringBuilder();            //获取Log组件
            ILogger log = LogManager.GetCurrentClassLogger();            var request = context.Request;

            sb.AppendLine("URL:");            //获取URL
            var url = request.RequestUri.ToString();
            sb.AppendLine(url);
           
            log.Error(context.Exception,sb.ToString(),"");
        }        public override bool ShouldLog(ExceptionLoggerContext context)
        {            return context.Exception is DemoException && base.ShouldLog(context);
        }
    }

In this example, we rewrite ShouldLog to ensure that this ExceptionLogger only records exceptions of the type DemoException, and The base class method is also called to ensure that the same exception will not be recorded repeatedly. In the LogAsync method, I recorded the request URL that caused the exception through the Log component, and also recorded the exception information.

Next we need to register this component:

Write

config.Services.Add(typeof(IExceptionLogger),new ErroLogger());

    public class ErrorHandler : ExceptionHandler
    {        public override async Task HandleAsync(ExceptionHandlerContext context, CancellationToken cancellationToken)
        {            if (context.Exception is DemoException)
            {
                context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.BadRequest,new {Message=context.Exception.Message}));
            }            else
            {
                context.Result = new ResponseMessageResult(context.Request.CreateResponse(HttpStatusCode.InternalServerError,new {Message = "服务器已被外星人绑架"}));
            }
        }
}

config.Services.Replace(typeof(IExceptionHandler),new ErrorHandler());

At this point, the simple development of the ExceptionLogger component and ExceptionHandler component is completed. During the development process, we can see that ExceptionLogger is responsible for global exception recording. ExceptionLogger will capture and record any unhandled exceptions that occur under the Web API framework pipeline. The functions of ExceptionHandler and ExceptionFilter overlap, so when to use ExceptionHandler and when to use ExceptionFilter? We can list the differences between the two in the following table:

The above is the detailed content of Asp.Net Web API exception handling experience summary. For more information, please follow other related articles on the PHP Chinese website!