Async Operations in Wcf: Handling Exceptions
Posted by Dan Rigsby on August 28th, 2008
Async Operations in Wcf Series:
Part 1: Event Based Model
Part 2: IAsyncResult Model (Client-Side)
Part 3: IAsyncResult Model (Server-Side)
Part 4: Canceling Operations
Part 5: Handling Exceptions
This is the fifth in a five part series on asynchronous operations in Wcf. If you are new to this series, you might want to read the first section of part one to get an introduction to this post: http://www.danrigsby.com/blog/index.php/2008/03/18/async-operations-in-wcf-event-based-model/
What happens when there is an exception
We have covered the ins and outs of working with asynchronous operations. But what happens in the unexpected happens? What happens if an Exception or FaultException occurs on the server? There are basically two situations:
- The exception is thrown before the thread is queued or before the thread context switch has happened. This would still be on the users’s initiated thread.
- The exception is thrown during the actual asynchronous operation on a different thread. This would be on some internal thread in the WCF service.
In situation 1, this acts like any other service call. Since the exception occurred on the same thread the client initiated, it is simply propagated back to the client like any other exception.
In situation 2, the exception occurs on a separate thread, so the client isn’t directly notified. Instead the server caches the exception and signals the client that the operation is complete. The client in turn will call its end operation completion method which will throw the exception back to the client. Keep in mind though, that if the exception is fatal to the service and beyond recovery, it can crash the service process itself.
Exception example
An example of this can be shown with a simple service that calculates a square root. In the call on the server, we have it wait 20 seconds before returning the result. However, if we throw an exception before the wait period, the client will get signaled immediately.
public double GetSquareRoot(double value) { // Throwing exception here causes the server to signal to // the client that the operation is complete and the exception // is rethrown on the client throw new FaultException("Fault before queuing thread."); Thread.Sleep(20000); // Wait 20 seconds return Math.Sqrt(value); }
You can download this full example here: http://www.danrigsby.com/Files/Rigsby.WcfAsyncOperationExceptions.zip
August 28th, 2008 at 2:51 pm
[...] Posted by Dan Rigsby on March 30th, 2008 Async Operations in Wcf Series: Part 1: Event Based Model Part 2: IAsyncResult Model (Client-Side) Part 3: IAsyncResult Model (Server-Side) Part 4: Canceling Operations Part 5: Handling Exceptions [...]
August 28th, 2008 at 2:53 pm
[...] Posted by Dan Rigsby on March 26th, 2008 Async Operations in Wcf Series: Part 1: Event Based Model Part 2: IAsyncResult Model (Client-Side) Part 3: IAsyncResult Model (Server-Side) Part 4: Canceling Operations Part 5: Handling Exceptions [...]
August 28th, 2008 at 3:00 pm
[...] Posted by Dan Rigsby on March 20th, 2008 Async Operations in Wcf Series: Part 1: Event Based Model Part 2: IAsyncResult Model (Client-Side) Part 3: IAsyncResult Model (Server-Side) Part 4: Canceling Operations Part 5: Handling Exceptions [...]
August 28th, 2008 at 3:02 pm
[...] Posted by Dan Rigsby on March 18th, 2008 Async Operations in Wcf Series: Part 1: Event Based Model Part 2: IAsyncResult Model (Client-Side) Part 3: IAsyncResult Model (Server-Side) Part 4: Canceling Operations Part 5: Handling Exceptions [...]
August 28th, 2008 at 3:56 pm
[...] Async Operations in Wcf: Handling Exceptions – Dan Rigsby [...]
August 29th, 2008 at 8:01 am
[...] Async Operations in WCF: Handling Exceptions (Dan Rigsby) [...]
March 26th, 2009 at 8:56 am
Hey Dan, I’m trying to create some consistency between our synchronous and asynchronous calls. We use a FaultContract with a custom error class containing additional useful information for our application. When coding for synchronous calls we obviously have a try/catch around the catch and are able to catch the FaultException with our contract such as follows:
try
{
decimal result = proxy.ExceptionTest(23);
}
catch (FaultException err)
{
…
}
Unfortunately with asynchronous calls the error information returned in the asynchronous call methods event args only contains the ‘outer’ exception with the FaultReason as the message. How can we get to our ErrorInfo FaultContact class in that asynchronous call? We are using the event-model based approach.
Thanks for your input.
March 26th, 2009 at 9:10 am
Hi again Dan,
As soon as I submitted this I found the answer. The e.Error object returned in the event args can be cast to the original FaultException definition granting access to the information.
July 11th, 2009 at 9:56 am
Hi Dan, thank you for this enlightening article and your good code.
Concerning exception handling though, I have a problem properly returning faultexceptions to the client using (server-side) async operations.
For example, if I try throwing a FaultException in the FindSquareRoot method, even if I use a try/catch block around the endGetSqareRoot on the client side, the exception never reaches the client (it just crashes the server).
Any help on this matter would be greatly appreciated.
July 12th, 2009 at 12:14 pm
In a web based envrionment you cant guarantee the callers to stick around necessary for their response. I have a similar issue where if the client process terminates before async response is recieved, the server crashes. In my case WCF server is hosted by a service. So, having to re-start the service manually each time is not feasible. Is there anyway to handle such situations on the server, and not causing the service to crash?