<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Async Operations in Wcf: Handling Exceptions</title>
	<atom:link href="http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/</link>
	<description>Developer.Speaker.Blogger</description>
	<lastBuildDate>Sun, 14 Aug 2011 06:09:27 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Anoosh</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-3280</link>
		<dc:creator>Anoosh</dc:creator>
		<pubDate>Sun, 12 Jul 2009 17:14:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-3280</guid>
		<description>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?</description>
		<content:encoded><![CDATA[<p>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?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nemphys</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-3278</link>
		<dc:creator>Nemphys</dc:creator>
		<pubDate>Sat, 11 Jul 2009 14:56:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-3278</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>Hi Dan, thank you for this enlightening article and your good code.<br />
Concerning exception handling though, I have a problem properly returning faultexceptions to the client using (server-side) async operations.<br />
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).<br />
Any help on this matter would be greatly appreciated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shannon Broskie</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-3022</link>
		<dc:creator>Shannon Broskie</dc:creator>
		<pubDate>Thu, 26 Mar 2009 14:10:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-3022</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>Hi again Dan,</p>
<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Shannon Broskie</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-3021</link>
		<dc:creator>Shannon Broskie</dc:creator>
		<pubDate>Thu, 26 Mar 2009 13:56:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-3021</guid>
		<description>Hey Dan, I&#039;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 &#039;outer&#039; 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.</description>
		<content:encoded><![CDATA[<p>Hey Dan, I&#8217;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:</p>
<p>try<br />
{<br />
decimal result = proxy.ExceptionTest(23);<br />
}<br />
catch (FaultException err)<br />
{<br />
&#8230;<br />
}</p>
<p>Unfortunately with asynchronous calls the error information returned in the asynchronous call methods event args only contains the &#8216;outer&#8217; 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.</p>
<p>Thanks for your input.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dew Drop - August 29, 2008 &#124; Alvin Ashcraft's Morning Dew</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-843</link>
		<dc:creator>Dew Drop - August 29, 2008 &#124; Alvin Ashcraft's Morning Dew</dc:creator>
		<pubDate>Fri, 29 Aug 2008 13:01:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-843</guid>
		<description>[...] Async Operations in WCF: Handling Exceptions (Dan Rigsby) [...]</description>
		<content:encoded><![CDATA[<p>[...] Async Operations in WCF: Handling Exceptions (Dan Rigsby) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arjan`s World &#187; LINKBLOG for August 28, 2008</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-839</link>
		<dc:creator>Arjan`s World &#187; LINKBLOG for August 28, 2008</dc:creator>
		<pubDate>Thu, 28 Aug 2008 20:56:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-839</guid>
		<description>[...] Async Operations in Wcf: Handling Exceptions - Dan Rigsby [...]</description>
		<content:encoded><![CDATA[<p>[...] Async Operations in Wcf: Handling Exceptions &#8211; Dan Rigsby [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Rigsby &#187; Async Operations in Wcf: Event Based Model</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-838</link>
		<dc:creator>Dan Rigsby &#187; Async Operations in Wcf: Event Based Model</dc:creator>
		<pubDate>Thu, 28 Aug 2008 20:02:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-838</guid>
		<description>[...] 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 [...]</description>
		<content:encoded><![CDATA[<p>[...] 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 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Rigsby &#187; Async Operations in Wcf: IAsyncResult Model (Client-Side)</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-837</link>
		<dc:creator>Dan Rigsby &#187; Async Operations in Wcf: IAsyncResult Model (Client-Side)</dc:creator>
		<pubDate>Thu, 28 Aug 2008 20:00:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-837</guid>
		<description>[...] 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 [...]</description>
		<content:encoded><![CDATA[<p>[...] 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 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Rigsby &#187; Async Operations in Wcf: IAsyncResult Model (Server-Side)</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-836</link>
		<dc:creator>Dan Rigsby &#187; Async Operations in Wcf: IAsyncResult Model (Server-Side)</dc:creator>
		<pubDate>Thu, 28 Aug 2008 19:53:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-836</guid>
		<description>[...] 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 [...]</description>
		<content:encoded><![CDATA[<p>[...] 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 [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Rigsby &#187; Async Operations in Wcf: Canceling Operations</title>
		<link>http://www.danrigsby.com/blog/index.php/2008/08/28/async-operations-in-wcf-handling-exceptions/comment-page-1/#comment-835</link>
		<dc:creator>Dan Rigsby &#187; Async Operations in Wcf: Canceling Operations</dc:creator>
		<pubDate>Thu, 28 Aug 2008 19:51:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.danrigsby.com/blog/?p=411#comment-835</guid>
		<description>[...] 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 [...]</description>
		<content:encoded><![CDATA[<p>[...] 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 [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

