debugcsharpModerate
Using a WCF service client and handling its exceptions
Viewed 0 times
handlingexceptionsclientserviceitsusingandwcf
Problem
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:
Is it good practice to close the proxy in a
Are there any better way of handling a WCF service client?
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 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?
Solution
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 :
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 :
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 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();
}Code Snippets
try
{
myServiceClient.Close();
}
catch
{
}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();
}Context
StackExchange Code Review Q#18319, answer score: 14
Revisions (0)
No revisions yet.