title: Handle persistent WCF client entering faulted state
body: <p>We've got a WCF service that we're consuming from a web app.  The client we're using was generated using the Visual Studio "Add Service Reference" option.  Since it's a web app, and since the nature of the app is likely to lead to relatively short sessions, we've opted to create an instance of the client when a user logs in and keep it around for the life of the session, then handle disposing of it when the session is through.</p>
  
  <p>This brings me to my question - we're trying to decide the best way to handle the client's channel entering a Faulted state.  After searching around some, we've come up with this:</p>
  
  <pre><code>if(client.State = CommuncationState.Faulted)
  {
      client = new Client();
  }
  
  try
  {
      client.SomeMethod();
  }
  catch //specific exceptions left out for brevity
  {
      //logging or whatever we decide to do
      throw;
  }
  </code></pre>
  
  <p>This, however, does not work due to the fact that, at least in our case, even if the service is down the client will show the <code>Open</code> state until you actually try to make a call using it, at which point it then enters the <code>Faulted</code> state.</p>
  
  <p>So this leaves us to do something else.  Another option we came up with was:</p>
  
  <pre><code>try
  {
      client.SomeMethod();
  }
  catch
  {
      if(client.State == CommunicationState.Faulted)
      {
          //we know we're faulted, try it again
          client = new Client();
          try
          {
              client.SomeMethod();
          }
          catch
          {
              throw;
          }
      }
      //handle other exceptions
  }
  </code></pre>
  
  <p>But that smells.  Obviously, we could avoid this by using a new client and disposing of it for every call.  That seems unnecessary, but if it's the right way then I guess that's what we'll opt for.  So what is the best way to gracefully handle determining if the client is in a faulted state and then doing something about it?  Should we really just be getting a new client for every call?</p>
  
  <p>One other thing to keep in mind - the instantiation of the client and all of this checking and handling happens in a wrapper class for the client.  If we do this the way we've intended to, it's transparent to the app itself - making calls and handling exceptions from them requires no special code there.</p>