Timeout Workaround


Believe it or not, but we did ship ADO.NET Data Services with a few bugs.    One issue in particular is fairly nasty.   However the code developers might be tempted to write to work around the bug could cause far worse problems down the road when we fix the initial bug.  Hence I wanted to give a quick write up to describe the issue and give a quick sample of how to write code that will work now and in the future when we fix the issue.


The problem exists in the ADO.NET Data Services client (System.Data.Services.Client.dll) we shipped with .NET 3.5 sp1 and Silverlight 2.0 SDK.  In particular, we do not throw the correct exception when a HTTP request has problems while being sent to the server.  I.e. a request timeouts, there is a bad server name, etc.  In other words, any problem that would normally raise a System.Net.WebException.  Unfortunately, in V1 of ADO.NET Data Services a NullReferenceException is raised instead of a WebException and even worse, the exception message is lost:


DataServiceContext context = 
     new DataServiceContext(
         new Uri(“http://BadServer/Northwind.svc”));
// Set small timeout amount to intentionally timeout request
context.Timeout = 1; 
DataServiceQuery<Customer> query = 
     context.CreateQuery<Customer>(“Customers”);

try
{
foreach (Customer c in query) { }
}
catch (NullReferenceException nre)
{
// in V1, NullReferenceException is

    //thrown instead of WebException.
// Also, no useful description
Console.WriteLine(“Something bad happened!”);
}

We are planning on fixing this bug in a future version of ADO.NET Data Services client (both in .NET and Silverlight) so if your code relies exclusively on catching the NullReference exception, it will be broken when we ship the fix.  Hence, to make your code robust – have your code explicitly catch both exception types:



DataServiceContext context = 
    new DataServiceContext(
        new Uri(“http://BadServer/Northwind.svc”));
// Set small timeout amount to intentionally timeout request
context.Timeout = 1;  
DataServiceQuery<Customer> query = 
    context.CreateQuery<Customer>(“Customers”);

try
{
foreach (Customer c in query) { }
}
catch (WebException e)
{
// When fix is shippped, will ADO.NET Data Services

    // will correctly throw webException
Console.WriteLine(e.Message);
}
catch (NullReferenceException nre)
{
// in V1, NullReferenceException is thrown
    // instead of WebException.
// Also, no useful description
Console.WriteLine(“Something bad happened!”);
}



We will update the team blog when we have a better idea of when the fix will be available.  All I can say now is we are looking into trying to get it out sooner than later, but we hope to have more information on this in the near future.


Andrew Conrad


ADO.NET Data Services Development Lead.

Comments (12)

  1. I wish these ping back stopped .

    ————–

    Thank you Andrew.

  2. While you’re at it, can you add an attribute similar to XmlIgnore so that I can add properties to my serialization classes that do not get serialized?

  3. PhaniRajuYN says:

    Hi Josh ,

    Take a look at this blog post which talks about how to customize the serialization of your client side entities ,

    http://blogs.msdn.com/phaniraj/archive/2008/12/11/customizing-serialization-of-entities-in-the-ado-net-data-services-client-library.aspx

  4. One way of doing Josh, work around for the current problem is to remove the properties you dont want on the WritingEntity event of the dataservicecontext. I have reused the IgnoreProperty attribute from the data.services namespace. I create a small class that will get the properties i want the serialization to ignore and I remove them from the atom feed. I can post it on my blog if you want it.

  5. Mind you that will not work if you are using json. and the post above PhaniRajuYN post link to site with some code that does what i have said.

  6. We are likely to see any more design notes posted here, besides Count?

  7. pabloc says:

    Yes, absolutely. We’ve just been heads-down working on finishing a number of things and haven’t had the change to write. We’ll definitely get back to it. Now that we got nag comments, even more so 🙂

    -pablo

  8. fantastic, yeah nag posts are good just mean ppl are paying attention. looking forward to more banter.

  9. ah one more thing when will ppl start using the post tags?

  10. Beim Arbeiten mit den ADO.NET Data Services (aka Astoria) kommt man irgendwann an den Punkt, dass die Aufgaben komplizierter werden oder die Last auf die Server steigen. In solchen Situationen ist man mit potentiellen Timeouts in allen Ebenen konfrontiert.

  11. Gideon says:

    hey, Im just hopelessly getting web exception timeouts for the last 3 hours but I have no clue whats wrong. Im just running a plan simple try out and the service works in a browser!?