views:

557

answers:

2

I want to know what are the cases in which WCF proxy (generated by vs2008 or svcutil) becomes faulted (fault state)? so I can recreate new instance and avoid use the faulted one.

currently I am handling TimeoutException,FaultException,CommunicationObjectAbortedException

            try
            {
                client.Method1(args);
            }
            catch (TimeoutException)
            {
                client.Abort();
                ReCreate();
            }
            catch (FaultException)
            {
                client.Abort();
                ReCreate();
            }
            catch (CommunicationObjectAbortedException)
            {
                client.Abort();
                ReCreate();
            }

I think I can avoid all these types and handle only the parent CommunicationException, is this sufficient? I need comments

A: 

WCF proxy object can become faulted because of any sort of exception except a faultException. So basically you best bet is just to check the proxy state and of it is faulted create a new one.

Another thing to keep in mind is that faulted is related to WCF sessions. If you don't need WCF sessions make sure to turn them off and you have prevented a whole series of possible issues.

Maurice
"WCF proxy object can become faulted because of any sort of exception except a faultException"Do you mean the generic FaultException<T> that decorates the service methods?
Ahmed Said
for "any sort of exception" does it mean if the service has something like "throw new Exception();" that will fault the session?
Ahmed Said
A FaultException<T> derives from and therefor is a FaultException. If the service does a "throw new Exception();" this will fault the proxy if sessions are used.
Maurice
+1  A: 

Any uncaught exception on the server side that isn't handled and converted into a FaultException or FaultException<T> will likely fault your channel. In a per-call scenario or a one-way scenario, you often don't really care about the channel being faulted, but in a session-based scenario, you definitely will!

Your best bet is to really try and catch all exceptions on the server side and either just suppress them (log them on the server and don't do anything), or return them to the client in a FaultException way.

In order to do that, your service implementation should also implement the IErrorHandler interface which allows you to do just that - catch all exceptions and either logging+suppressing them, or converting them to SOAP faults.

Marc

marc_s
In case of expected exceptions like (UnauthorizedAccessException or any) that the server throws, it will fault the session and the client should take of that!!
Ahmed Said
Yes, there are some cases where you will want to propagate the exception to the client - but that's the exception rather than the rule
marc_s