Client state after FaultException

Client state after FaultException

• Laurent Kempé

  you can cast the proxy to IClientChannel which inherit from ICommunicationObject and has a state property you can use to check its state.
  

• Aaron Sulwer

  So, what you should do is always check the state of the proxy after catching an exception. If it is faulted, a new session is required, and you must reconstruct the proxy.

  Just a question: how do I check the state of a client proxy The proxy itself does only contain those functions I added to it, so it must be somewhere else.

  The ChannelFactory got a state, but this can't be for the client proxy, can it I would not know which client proxy is faulted, I might have more than one from this factory at any one time.

  (I'm not reusing the proxy, I just like to have this information so the dispose of my client does not try to Close the proxy but instead abort it)

  Thanks,
  Sam

  
  

• ACHawk

  The problem is not the FaultException. You will always receive some form of FaultException at the client when an exception or fault is thrown by the server. THe problem is in the TYPE of FaultException.

  If the service throws an exception of any type, it faults the server channel. If there is a session (TCP has a transport session, WSHttp might have reliable session or secure session, any service might have an application session if configured so)...the session is faulted, and the client proxy is rendered useless.

  If the service throws a FaultException of any type, instead of throwing an exception, the channel is not faulted. Examples (the latter is a data contract):

  throw new FaultException("Invalid operation.");

  throw new FaultException<InvalidOperationException>(new InvalidOperationException("This is an invalid operation."), "Invalid operation.");

  throw new FaultException<ReceiverFaultDetail>(new ReceiverFaultDetail("Here are the details of the exception."), "Receiver fault.");

  Either way, the client receives a fault, but the state of the proxy channel will not be faulted. So, what you should do is always check the state of the proxy after catching an exception. If it is faulted, a new session is required, and you must reconstruct the proxy.

  If the faults are declared in the service contract, then the client knows what types of exception "might" be thrown that will NOT fault the channel.

  
  
  

• rohit_c4u

  joe zhou - MSFT wrote:

  you can cast the proxy to IClientChannel which inherit from ICommunicationObject and has a state property you can use to check its state.

  Ah, thanks a lot!

  Sam

  
  
• Client state after FaultException