Benutzer mit den meisten Antworten
WCF ErrorHandler und SoapException

Frage
-
Hi,
ich habe einen WCF Service für den ich einen ErrorHandler Implementiert habe. Nun habe ich nach einigem hin und her festgestellt, das der ErrorHandler nicht aufgerufen wird, wenn es sich bei der geworfenen Exception um eine SoapException handelt bzw. diese als Inner Exception vorhanden ist. Das gleiche Problem gilt wohl auch für XML serialisierbare Exceptions, wie man in einigen Foren lesen kann. Meine Frage ist nun, ob man das irgendwo konfigurieren kann, so dass der ErrorHandler immer aufgerufen wird, egal welcher Typ von Ausnahme geworfen wird. Ich konnte auch nicht rausfinden, ob das nun ein Feature oder ein Bug im WCF Framework ist. Gibt es dazu irgendwo Informationen!?
Gruß
Martin
Mittwoch, 10. April 2013 08:15
Antworten
-
Hi Martin,ich habe das so verstanden, dass Du im IIS einen WCF-Service hostest, der aus zwei Teilen besteht, dem WCF-Service und dem Remoting (kein WCF), welches mit einem Service auf dem gleichen Rechner verbunden ist. Dieser Service verpackt Exceptions, die er mitgeteilt bekommt (nicht vom WCF-Service), in ein eigenes Exception-Objekt und löst damit eine Exception in der Remote-Verbindung aus. Diese im Remote-Objekt ausgelöste Exception soll dann im WCF-Service als FaultObject dem Client mitgeteilt werden.Wenn das so ist, dann vermute ich, dass in der Remote-Verbindung, die synchron arbeitet, Ereignisse “verschluckt” werden. Interessant wäre zu wissen, wie viel Zeit die Remoteverbindung verbraucht und ob Puffertechniken mit Auslagerung der Verarbeitung der anfallenden Ereignisse in separate threads genutzt werden.--
Peter Fleischer- Als Antwort markiert Martin Horst Mittwoch, 17. April 2013 10:59
Freitag, 12. April 2013 06:24
Alle Antworten
-
Hallo Peter,
ich habe eben mal testweise eine SoapException von Hand geworfen und diese landet auch im Error Handler. Bei meinem Problem wird die SoapException von einem externen Webservice geworfen, dann auf einem Server in eine eigene Exception Klasse verpackt und welcher wiederum von der Webanwendung per Remoting aufgerufen wird, die den Error Handler beinhaltet. Die Webanwendung fungiert als eine Art Proxy. Die Aufrufliste sieht grob so aus:
ASMX Webservice <-> Server (Windows Dienst) <-> Webserver mit WCF Service <-> Windows Client.
Und in diesem Fall kommt die Exception zwar auf dem Webserver an (Debugger), wird aber nicht dem Error Handler übergeben. Den Error Handler registriere über an angehängten Code. Für alle anderen Ausnahmen funktioniert das ganze ja auch ohne Probleme.
Gruß
Martin
public class PaErrorHandlerBehaviourAttribute : Attribute, IServiceBehavior { public void AddBindingParameters(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase, System.Collections.ObjectModel.Collection<ServiceEndpoint> endpoints, System.ServiceModel.Channels.BindingParameterCollection bindingParameters) { } public void ApplyDispatchBehavior(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase) { foreach ( ChannelDispatcherBase lChannelDispatcherBase in serviceHostBase.ChannelDispatchers ) { ChannelDispatcher lChannelDispatcher = lChannelDispatcherBase as ChannelDispatcher; if ( lChannelDispatcher != null ) { PaServiceErrorHandler lPaServiceErrorHandler = new PaServiceErrorHandler(); lChannelDispatcher.ErrorHandlers.Add(lPaServiceErrorHandler); } } } public void Validate(ServiceDescription serviceDescription, System.ServiceModel.ServiceHostBase serviceHostBase) { } }
Donnerstag, 11. April 2013 11:53 -
Hi Martin,ich habe das so verstanden, dass Du im IIS einen WCF-Service hostest, der aus zwei Teilen besteht, dem WCF-Service und dem Remoting (kein WCF), welches mit einem Service auf dem gleichen Rechner verbunden ist. Dieser Service verpackt Exceptions, die er mitgeteilt bekommt (nicht vom WCF-Service), in ein eigenes Exception-Objekt und löst damit eine Exception in der Remote-Verbindung aus. Diese im Remote-Objekt ausgelöste Exception soll dann im WCF-Service als FaultObject dem Client mitgeteilt werden.Wenn das so ist, dann vermute ich, dass in der Remote-Verbindung, die synchron arbeitet, Ereignisse “verschluckt” werden. Interessant wäre zu wissen, wie viel Zeit die Remoteverbindung verbraucht und ob Puffertechniken mit Auslagerung der Verarbeitung der anfallenden Ereignisse in separate threads genutzt werden.--
Peter Fleischer- Als Antwort markiert Martin Horst Mittwoch, 17. April 2013 10:59
Freitag, 12. April 2013 06:24 -
Hallo Martin,
sollte Dir die Antwort von Peter Fleischer geholfen haben, dann markiere sie bitte als Antwort.
Grüße,
Stefan Kleinewillinghoefer, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwicklern“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden koennen.
Dienstag, 16. April 2013 07:35 -
Hallo Peter,
also die Remoting Aufrufe an den Service werden direkt in den Methoden des WCF-Service durchgeführt (welcher im IIS gehostet wird). Puffertechniken gibt es da nicht, die Aufrufe werden einfach eins zu eins weitergereicht. Interessant ist eben, dass das für alle Ausnahmen funktioniert. Auch für die gleiche Ausnahme und Methode auf dem Service, wenn man eben die SoapException nicht als innere Ausnahme einträgt. Ich habe auch testweise einfach mal einen anderen Typ von Ausnahme als innere Ausnahme eingetragen und auch dann funktionierte es. Deswegen bin ich davon ausgegangen, dass mit SoapExceptions irgendwie anders verfahren wird. Es handelt sich zum Glück nur um eine Stelle, da wir so langsam von den alten ASMX Webservices weggehen. Ich werden das Ganze aber noch im Auge behalten, evtl. findet sich ja noch ein anderer Grund.
Gruß
Martin
Mittwoch, 17. April 2013 10:59