The uncatchable exceptions in WCF clients

Did you ever have a problem with a WCF client throwing exceptions you can't catch?

If you have used WCF clients from Windows Phone, Silverlight or Xamarin.iOS, you might have noticed that it is not possible to create Synchronous or Task-Based operations; the functionality is reduced to the Event-based Asynchronous Pattern (EAP). That means that the way to call a WCF method and get the response is usually as follows:

var client = new MyWCFClient();
client.DownloadDataCompleted += (sender, e) =>
{
 try
 {     
     //accessing e.Result here might raise an exception in another
     //thread, that will not be captured by the 'catch' below.
 }
 catch(Exception ex)
 {
 }
};
client.DownloadDataAsync(url);


Our results are wrapped in an auto-generated class that inherits from AsyncCompletedEventArgs, this class has a property Error of type Exception, that will carry information about the error and a property Result with our expected return value.

Accessing the property Result after a failed operation call, might cause cause an exception like this one: "An exception of type 'System.ServiceModel.CommunicationException' occurred in System.ServiceModel.ni.dll but was not handled in user code", you will also realize there is no place in your code that you could place a try-catch to capture it, and your application crashes...


The cause of the problem

The behavior is partially "by design". A quick look at the client  generated  code and you will find the root of the problem. The implementation of DownloadDataCompletedEventArgs contains this code:

 public MyTest.WrappedResultOfstring Result {
            get {
                base.RaiseExceptionIfNecessary();
                return ((MyTest.WrappedResultOfstring)(this.results[0]));
            }
        }
So they actually planned to throw an exception if there is something wrong with the operation, which is a good approach actually. However the exception is raised  in another thread.

The solution 

You must first check if the operation failed, and if it did, don't read the property Result, if you do it, then the exception will rise in another thread and it won't be possible to catch it, causing your application to fail. And in the case of Windows Phone and the other mobile apps, that means getting your app rejected from the store. Here is how you should always handle responses from WCF clients.

client.DownloadDataCompleted += (sender, e) =>
{
    if (e.Error != null)
            {
                //...
                //handle the error
                //but never even read from e.Result
            }
            else
            {
                // do something with e.Result
            }
};

Why the exception is raised in another thread is beyond me, however the solution to prevent it just implies a bit of good programming practices and nothing more.

Comments

Post a Comment

Popular posts from this blog

Get-ChildItem vs Dir in PowerShell

Image
Batch as usual Recently I was in the need of modifying a huge amount of files across a network share. After installing Serviio media streaming service I noticed that it will crash "randomly". After checking the logs it was clear that ffmpeg was crashing when trying to open subtitle files that were not in the encoding indicated by the Serviio console. I needed a quick way to update all subtitle files to a common encoding, so I decided to convert all files to UTF8. Since I use a windows environment I went directly to PowerShell and wrote this.  Get-ChildItem -path .\ -filter *.srt -file  | ForEach-Object { (get-content $_.FullName) | Out-File $_.FullName -encoding utf8 } This worked almost right except for files with "[" or "]" (among other symbols) on the name or path. To solve it, just added the "-LiteralPath" switch to tell powershell not to consider any wildcards on the path name and just use it exactly as it is.  Get-ChildIt
Read more

The case for a 4 week sprint

Image
Every time we talk about SCRUM, the length of the sprint is stated as a period of "two to four weeks", rarely, however, have I seen people going outside of the 2 weeks. This is not written on stone of course, and while 3 weeks might seems odd, there is a benefit to using a longer period for your sprints.  Image is taken from scrum.org Without any hard data to back that decision, the answer I get from asking about this decision seems to be related to "delivery speed", we assume that because we deliver value to the business every 2 weeks, we are in a more "agile" environment. Well, that might not be so true in every sense or for every project. Let's break some arguments: 1. Sprint length is not equal to the speed of delivery There is more to the speed of development and delivery than the timeframe of the delivery cycle, in a world with DevOps and full CI/CD implemented for your project, you could (should?) actually deliver features every single day all t
Read more

NODE.js fs.readFile and the BOM marker

Working on a ReactJS project, got a small glitch while trying to read a JSON file and parse it as a javascript object. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString); } output:   SyntaxError: Unexpected token   After checking, double and triple checking again that the file was correct I went deeper and realized that "fs.readFileSync" was returning me the BOM for the UTF file at the beginning of the string. So we just need to strip it out. getDataObject() { var dataString = fs.readFileSync("./json/data.json", "utf8"); return JSON.parse(dataString.replace(/^\uFEFF/, "")); } I then checked and there are "packages" for this, however I don't think is proper to just import a new dependency just to fix something this small. The big issue here is why is this considered correct. The BOM is not
Read more