Ich habe eine Menge Legacy-Code, der jetzt ein Backend für einen WCF-REST-Service ist - früher war es ein gewöhnliches WCF-Service-Backend, wenn das wichtig ist. Ich möchte einen Mechanismus implementieren, der jede Ausnahme in irgendeiner Methode fängt und analysiert. Wenn sich herausstellt, dass es sich um einen bekannten Fehler handelt, wird dieser verarbeitet und in einen freundlich aussehenden Fehler umgewandelt.
Ich weiß, dass ich FaultException oder WebProtocolException anstelle von 'normalen' Ausnahmen ausgeben kann, aber es gibt viele Orte, an denen Ausnahmen über den gesamten Code verteilt werden, und die Suche nach allen ist eine ziemlich schmerzhafte Option.
Ich habe versucht, eine Endpunktverhaltenserweiterung hinzuzufügen, die ein neues Verhalten erstellt, das die standardmäßige WebHttpBehavior.AddServerErrorHandlers -Methode überschreibt, und fügt meine Fehlerbehandlungsroutinen ( IErrorHandler -Implementierungen) der Fehlerbehandlungsroutine der Endpoint-Dispatcher hinzu. Innerhalb der Fehlerhandler analysiere ich die Ausnahme und erstelle (oder erstelle nicht) einen gewünschten Fehler basierend auf dieser Ausnahme.
Ich habe erwartet, dass dieser Mechanismus benutzerdefinierte Daten für jede bekannte Ausnahme zurückgibt, aber ich lag falsch. Gute alte Microsoft hat eine wunderbare unvermeidliche WebHttpBehavior2 implementiert, die unbedingt eine interne Microsoft.ServiceModel.Web.WebErrorHandler am Ende der Endpoint Dispatcher Fehlerhandlersammlung hinzufügt. Dieser Handler ignoriert alle zuvor ausgeführten Handler und erkennt nur eine kleine Anzahl von Ausnahmen, während die Mehrheit als "Interner Serverfehler" interpretiert wird und nicht mehr.
Die Frage ist, ob ich auf einem richtigen Pfad bin und es gibt eine Möglichkeit, diesen Handler im WCF-REST-Mechanismus zu deaktivieren oder mit einer neuen Exception einzuführen (z. B. wenn eine Ausnahme abgefangen wird, wird sie zuerst von meinen Handlern verarbeitet) und wenn sie beispielsweise FaultException auslösen / zurückgeben, wird diese neue Ausnahme an Microsoft.ServiceModel.Web.WebErrorHandler anstelle des ursprünglichen übergeben. Wenn alle meine Experimente mit IErrorHandler und Verhaltenserweiterungen wertlos sind, was ist eine Alternative? Auch hier möchte ich die Exception-Throw-Logik nicht ändern. Ich möchte einen Ort, um die Ausnahmen zu erfassen und zu verarbeiten.
Vielen Dank!
Wenn Sie die WCF SOAP-Dienste in REST ändern, ändert sich die gesamte Denkweise der Fehlerberichterstattung und -behandlung.
In SOAP sind Fehler Teil Ihres Vertrags. In REST werden sie einfach zu Codes, die Sie im HTTP-Antwortcode und in der Beschreibung ausgeben.
Hier ist ein Fangschnipsel:
%Vor%Also würde ich vorschlagen, dass Sie einen Hilfscode erstellen, der relevante Fehlercodes für Sie erstellt und die Antwort einfügt.
Das, was ich in der Vergangenheit gemacht habe
%Vor%MyErrorHandler war meine Klasse, die IErrorHandler implementiert hat.