Asp.Net Web API exception handling experience summary-C#.Net Tutorial-php.cn

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);
        }
    }

Copy after login

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());

Copy after login

# in the Register method in the App_Start/WebApiConfig.cs file ## In this way, an exception recording component for DemoException has been developed and registered. When an unhandled DemoException occurs in the Web API execution pipeline, this component will be called for recording.

Next we write an ExceptionHandler. In the entire Web API framework, ExceptionHandler can only provide one instance. Like ExceptionLogger, we can inherit the ExceptionHandler base class to simplify exception handling. ShouldHandle is also provided in ExceptionHandler Method to determine whether the exception should be handled to avoid repeatedly handling exceptions thrown repeatedly by other links in the pipeline. We also provide an example:

    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 = "服务器已被外星人绑架"}));
            }
        }
}

Copy after login

In this example, we determine the type of exception and return different response content and different content to the client based on different exceptions. HTTP status code.

Then register this exception handling module in the configuration and write

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

Copy after login

in the Register method in the App_Start/WebApiConfig.cs file. This will replace The system's default ExceptionHandler can be used to handle exceptions using our custom Handler.

During the exception recording and processing process, we all encounter the corresponding exception context parameter. We can use this parameter to obtain the context of the current request, obtain the request, response (be careful, sometimes it will be empty), and capture We can use this information to better describe, record, and handle exceptions, such as the exception's catch block information.

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:

##Action conditionsControllerWeb API We can see from the above table that if the processing granularity is as detailed as the Controller and Action levels, the ExceptionFilter will be easier to handle. He has been able to pinpoint a certain Action and can then do customized development for the current Action. The scope of ExceptionHandler is much larger than that of ExceptionFilter, and it has more advantages in handling the global situation.

	ExceptionFilter	ExceptionHandler
##Scope	Controller、Action	##Global
Number of instances	Unlimited	Globally unique
	After successful instantiation	Loaded successfully After

I will talk about this about Web API exception handling. If there are any errors or questions in the article, you are welcome to point them out to me.

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!