Question

I’ve got a Silverlight enabled WCF web service set up and I’m connecting to it from my Silverlight application.

The Service is not written using the ASync pattern but Silverlight generates the async methods automatically.

I have a method that within my service that has a chance of throwing an exception I can catch this exception but I’m not sure of the best way of handling this exception, I’ve noticed that the event args of the completed method contain an error property.

Is is possible to set the value of this error property?

Example Method

public class service
{
    [OperationContract]
    public Stream getData(string filename)
    {
        string filepath = HostingEnvironment.MapPath(filename);
        FileInfo fi = new FileInfo(filenpath);

        try
        {
            Stream s = fi.Open(FileMode.Open);

            return s;
        }
        catch (IOException e)
        {
            return null;
        }
    }
}

Silverlight Code

btnFoo_Click(object sender, RoutedEventArgs e)
{
   ServiceClient svc = new ServiceClient();

   svc.getDataCompleted += new EventHandler<getDataCompletedEventArgs>(getData_Completed);
   svc.getDataAsync("text.txt");
}

void getData_Completed(object sender, getDataCompletedEventArgs e)
{
   e.Error //how can i set this value on the service?
}

Finally if the service is offline or times out is there anyway to catch this exception before it reaches the UnhandledException method within App.xaml?

Thanks

Answer 1

Since silverlight is using services asyncronously you dont get a synchronous exception throw, but instead it is stored in e.Error property, that you need to check in your ServiceCallCompleted method.

To answer your question

how can i set this value on the service?

Simply throw an exception on server and it can be enough given several other conditions.

You may want to introduce FaultContract on your WCF service method, and throw FaultException<T> which is a common way to deal with errors in WCF.

However fault result in return code 500 and silverlight won’t be able to get response with such status code and have access to Fault object, even if you add that attribute to service.

This can be solved using several approaches.

• Use the alternative client HTTP stack: You can register an alternative HTTP stack by using the RegisterPrefix method. See below for an outline of how to do this. Silverlight 4 provides the option of using a client HTTP stack which, unlike the default browser HTTP stack, allows you to process SOAP-compliant fault messages. However, a potential problem of switching to the alternative HTTP stack is that information stored by the browser (such as authentication cookies) will no longer be available to Silverlight, and thus certain scenarios involving secure services might stop working, or require additional code to work.
• Modify the HTTP status code: You can modify your service to return SOAP faults with an HTTP status code of 200, Silverlight 4 so that faults will be processed successfully. How to do this is outlined below. Note that this will make the service non-compliant with the SOAP protocol, because SOAP requires a response code in the 400 or 500 range for faults. If the service is a WCF service, you can create an endpoint behavior that plugs in a message inspector that changes the status code to 200. Then you can create an endpoint specifically for Silverlight consumption, and apply the behavior there. Your other endpoints will still remain SOAP-compliant.

Faults in silverlight