14
\$\begingroup\$

I am new to WCF and need to work with another programmer's code. I am unsure of the way the WCF service client is used here:

private void barButtonDocuments_ItemClick(object sender, ItemClickEventArgs e)
{
    try
    {
        MyServiceClient myServiceClient = new MyServiceClient();

        try
        {
            documents = myServiceClient.GetDocuments();
            // More code that isn't useful including here ...
        }
        finally
        {
            try
            {
                myServiceClient.Close();
            }
            catch
            {
            }
        }
    }
    catch (FaultException<ServiceErrorDetails> error)
    {
        MessageBox.Show(error.Detail.Message, "Erreur", MessageBoxButtons.OK, MessageBoxIcon.Error);
    }
}

Is it good practice to close the proxy in a finally block, and doing so in an additional try/catch block? I personally don't like the empty catch block because it's like hiding potentially useful exceptions when trying to close the service client.

Are there any better way of handling a WCF service client?

\$\endgroup\$
  • \$\begingroup\$ You may be interested in this WCF approach I asked about here: codereview.stackexchange.com/q/41692/1714 \$\endgroup\$ – goodguys_activate Feb 14 '14 at 21:41
  • \$\begingroup\$ Any final solution with full source code sample application ? IMHO, better samples for minimize learning curve are real applications with full source code and good patterns \$\endgroup\$ – Kiquenet Sep 25 '14 at 8:23
13
\$\begingroup\$

Although paritosh's answer is very helpful, there is additional useful information to take into account when using a service client, as found in this MSDN article :

It is recommended that a calling application open the channel, use it, and close the channel inside one try block.

Let's look at the original try/catch block that was used for the solely purpose of closing the channel :

    try
    {
        myServiceClient.Close();
    }
    catch
    {
    }

This is useless, as stated in the article :

Datagram channels never fault even if exceptions occur when they are closed.

About handling exceptions, MSDN suggests that no unexpected exceptions (like OutOfMemoryException, ArgumentNullException or InvalidOperationException) should be caught when using a service client, as stated in this MSDN article :

Exceptions that are thrown from communication methods on a Windows Communication Foundation (WCF) client are either expected or unexpected. Unexpected exceptions include catastrophic failures like OutOfMemoryException and programming errors like ArgumentNullException or InvalidOperationException. Typically there is no useful way to handle unexpected errors, so typically you should not catch them when calling a WCF client communication method.

Recommended exceptions to catch while using a service client are TimeoutException and any other exception that derives from CommunicationException.

As the article states :

One way to handle such errors is to abort the client and report the communication failure.

In addition, as this particular project handles it's own FaultException (of type ServiceErrorDetails), the recommended method to catch exceptions while using this service client would be to first catch any TimeoutException, then any FaultException and finally any CommunicationException.

The rewritten code would then look like this :

MyServiceClient myServiceClient = new MyServiceClient();

try
{
    documents = myServiceClient.GetDocuments();
    // More code that isn't useful including here ...
    myServiceClient.Close();
}
catch (TimeoutException exception)
{
    MessageBox.Show(exception.Message, "Timeout error", MessageBoxButtons.OK, MessageBoxIcon.Error);
    myServiceClient.Abort();
}
catch (FaultException<ServiceErrorDetails> error)
{
    MessageBox.Show(error.Detail.Message, "Service error", MessageBoxButtons.OK, MessageBoxIcon.Error);
    myServiceClient.Abort();
}
catch (CommunicationException exception)
{
    MessageBox.Show(exception.Message, "Communication error", MessageBoxButtons.OK, MessageBoxIcon.Error);
    myServiceClient.Abort();
}
\$\endgroup\$
  • \$\begingroup\$ Which exceptions with statusCode for do Retry ? \$\endgroup\$ – Kiquenet Mar 22 '18 at 14:44
  • \$\begingroup\$ ServiceErrorDetails is custom class ? \$\endgroup\$ – Kiquenet Mar 22 '18 at 14:45
4
\$\begingroup\$

Use Close always for a clean path of code execution. Use Abort in case of a faulted channel, or if your code threw an error. As you might know, if you call Close on a faulted channel, it will throw another error, Close is a graceful shutdown of channel, whereas Abort is an instant shut down of the channel. Here's an example of such code:

MyServiceClient myServiceClient = new MyServiceClient();

try
{
    documents = myServiceClient.GetDocuments();
    // More code that isn't useful including here ...
    myServiceClient.Close();
}
catch(Exception ex)
{
    myServiceClient.Abort();
}
\$\endgroup\$
  • 1
    \$\begingroup\$ Thanks for your answer. I didn't know about Abort(), very useful in case something's wrong with the service code. Now, I can be sure that the channel is shut down. \$\endgroup\$ – user19024 Nov 7 '12 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy