Zusammenfassung der Erfahrungen mit der Asp.Net-Web-API-Ausnahmebehandlung

Im vorherigen Tutorial habe ich Ihnen die Entwicklung und Verwendung von Filter in der Web-API vorgestellt. Beim Thema ExceptionFilter gab es eine Gefahr: ExceptionFilter kann nur Ereignisse abfangen und verarbeiten, die während der Aktionsausführung auftreten . Ausnahme: Wenn eine Ausnahme außerhalb des Aktionsausführungsprozesses auftritt, ist ExceptionFilter machtlos.

Zu diesen Ausnahmen gehören:

1. Ausnahmen, die in der Controller-Konstruktionsmethode auftreten

2. Ausnahmen, die in MessageHandlern auftreten

3. Ausnahmen, die auftreten während des Routing-Prozesses Ausnahmen

4. Ausnahmen, die während des Serialisierungs-/Deserialisierungsprozesses von Body auftreten

Es ist ersichtlich, dass ExceptionFilter nur die Ausnahmen lösen kann, die auftreten, nachdem der ApiControler erfolgreich instanziiert wurde und während der Ausführung von Action. Exceptions; Um dieses Problem zu lösen, werden zusätzlich zu ExceptionFilter zwei Erweiterungspunkte für die Ausnahmeaufzeichnung und -verarbeitung in der WEB-API eingeführt:

IExceptionLogger und IExceptionHandler.

und diese beiden Erweiterungen werden als Pipeline-Komponenten der Web-API registriert und verwaltet und haben eine unterschiedliche Arbeitsteilung:

IExceptionLogger als abnormale Protokollaufzeichnungskomponente, die für das Protokoll verantwortlich ist Die Aufzeichnung erfolgt über den gesamten Web-API-Lebenszyklus. Jede nicht erfasste/behandelte Ausnahme in einem beliebigen Anforderungszyklus gelangt zunächst in die Ausnahmeprotokollierungspipeline. In der Web-API können mehrere IExceptionLogger-Instanzen registriert werden für die unterschiedliche Ausnahmebehandlung verantwortlich sein.

Als Ausnahmebehandlungskomponente ist IExceptionHandler für die Verarbeitung verantwortlich, nachdem Ausnahmen aufgetreten sind. Er befindet sich am Ende der Ausnahmebehandlungspipeline, wenn die IExceptionLogger-Komponente eine Aufzeichnung abschließt und kein zugehöriger ExceptoinFilter für die Ausnahmebehandlung vorhanden ist wird schließlich ExceptionHandler für die Ausnahmebehandlung aufrufen. In der Web-API gibt es nur einen ExceptionHandler für die Ausnahmebehandlung.

Es gibt zwei Basisklassen im Web-API-Framework: ExceptionLogger und ExceptionHandler. Bei Verwendung der ExceptionLogger-Basisklasse wird die Methode ShouldLog in der Basisklasse aufgerufen Dieselbe Ausnahme wird wiederholt von derselben ExceptionLogger-Instanz aufgezeichnet (wenn die Ausnahme beispielsweise in der nachfolgenden Pipeline erneut ausgelöst wird oder dasselbe ExceptionLogger-Objekt versehentlich zweimal registriert wird, besteht die Möglichkeit einer wiederholten Aufzeichnung. Wir können ShouldLog auch überschreiben). Fügen Sie unsere eigene Ausnahmedatensatz-Beurteilungslogik hinzu, um unterschiedliche ExceptionLogger-Aufrufe für verschiedene Szenarien durchzuführen. Wenn Sie interessiert sind, können Sie die Basisklasse ExceptionLogger dekompilieren und einen Blick darauf werfen. Sie verwendet die Implementierung der Anzeigeschnittstelle, was eine sehr interessante Technik ist. Schauen wir uns ein Beispiel für die Verwendung von ExceptionLogger an:

    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 diesem Beispiel schreiben wir ShouldLog um, um sicherzustellen, dass dieser ExceptionLogger nur Ausnahmen vom Typ DemoException aufzeichnet Ruft die Basisklassenmethode auf, um sicherzustellen, dass dieselbe Ausnahme nicht wiederholt aufgezeichnet wird. In der LogAsync-Methode habe ich die Anforderungs-URL, die die Ausnahme verursacht hat, über die Protokollkomponente sowie die Ausnahmeinformationen aufgezeichnet.

Als nächstes müssen wir diese Komponente registrieren:

Schreiben Sie

Auf diese Weise wurde eine Ausnahmeaufzeichnungskomponente für DemoException entwickelt und registriert. Wenn eine nicht behandelte DemoException in der Web-API-Ausführungspipeline auftritt, wird diese Komponente zur Aufzeichnung aufgerufen.

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

Als nächstes schreiben wir einen ExceptionHandler. Wie ExceptionLogger können wir auch die ExceptionHandler-Methode erben, um die Ausnahmebehandlung zu vereinfachen Bestimmen Sie, ob die Ausnahme behandelt werden soll, um die wiederholte Behandlung von Ausnahmen zu vermeiden, die von anderen Links in der Pipeline wiederholt ausgelöst werden. Wir stellen auch ein Beispiel zur Verfügung:

In diesem Beispiel ermitteln wir die Art der Ausnahme und geben basierend auf verschiedenen Ausnahmen unterschiedliche Antwortinhalte an den Client zurück Codes.

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

Registrieren Sie dann dieses Ausnahmebehandlungsmodul in der Konfiguration und schreiben Sie

in die Register-Methode in der Datei App_Start/WebApiConfig.cs. Auf diese Weise Der standardmäßige ExceptionHandler des Systems wurde ersetzt und unser benutzerdefinierter Handler kann zur Behandlung von Ausnahmen verwendet werden.

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

Während des Ausnahmeaufzeichnungs- und -verarbeitungsprozesses stoßen wir alle auf den entsprechenden Ausnahmekontextparameter. Wir können diesen Parameter verwenden, um den Kontext der aktuellen Anforderung abzurufen, die Anforderung und die Antwort abzurufen (seien Sie vorsichtig, manchmal ist dies der Fall). leer), Capture Wir können diese Informationen verwenden, um Ausnahmen besser zu beschreiben, aufzuzeichnen und zu behandeln, z. B. die Catch-Block-Informationen der Ausnahme.

An diesem Punkt ist die einfache Entwicklung der ExceptionLogger-Komponente und der ExceptionHandler-Komponente abgeschlossen. Während des Entwicklungsprozesses können wir sehen, dass ExceptionLogger für die globale Ausnahmeaufzeichnung verantwortlich ist und alle nicht behandelten Ausnahmen erfasst und aufzeichnet, die unter der Web-API-Framework-Pipeline auftreten. Die Funktionen von ExceptionHandler und ExceptionFilter überschneiden sich. Wann sollte also ExceptionHandler und wann ExceptionFilter verwendet werden? Die Unterschiede zwischen den beiden können wir in der folgenden Tabelle auflisten:

	ExceptionFilter	ExceptionHandler
作用域	Controller、Action	全局
实例个数	无限制	全局唯一
作用条件	Controller实例化成功之后	Web API成功加载之后

ExceptionFilter

ExceptionHandler

Umfang

Controller, Aktion

global

Anzahl der Instanzen

Unbegrenzt

Weltweit einzigartig

Aktionsbedingungen

ControllerNach erfolgreicher Instanziierung

Web-API Nach erfolgreichem Laden

Nach der obigen Tabelle Wir können sehen Wenn die Verarbeitungsgranularität so detailliert ist wie die Controller- und Aktionsebenen, ist ExceptionFilter einfacher zu handhaben. Es kann bereits eine bestimmte Aktion genau lokalisieren und dann eine benutzerdefinierte Entwicklung für die aktuelle Aktion durchführen. Der Umfang von ExceptionHandler ist viel größer als der von ExceptionFilter und bietet mehr Vorteile bei der Bewältigung globaler Situationen. Das ist alles, was ich zur Web-API-Ausnahmebehandlung zu sagen habe. Wenn der Artikel Ungenauigkeiten oder Fragen enthält, können Sie mich gerne darauf hinweisen.

Das obige ist der detaillierte Inhalt vonZusammenfassung der Erfahrungen mit der Asp.Net-Web-API-Ausnahmebehandlung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!