Handling service exceptions within Silverlight applications

Most LOB applications in Silverlight work with services to get data to the client. Commonly used technologies on the server-side include WCF, WCF RIA Services and REST Services. When all communication with the service goes well and no service exceptions occur, the Silverlight application has nothing to worry about: it will get its data to display to the user. But what happens when things go down the drain on the server? The database can be down, the load on the server might be too high or a third-party service that needs to be invoked can’t be connected to. We can handle this on the server-side but we should be able to let the end-user know what went wrong. Perhaps, since it’s only a temporary problem, we’d like him to try again in a few seconds.

For that reason, we need to be able to capture the faults on the client. Also, during development, it’s vital to work productively that we know what went wrong within our service. The problem is that Silverlight does not get access to this information, being a browser plugin. There are two solutions available to solve this problem. This article shows you how you can get access to this information and also explains which solution should be followed in what situation.

The source code for this article can be downloaded here.

The cause of the problem

If from Silverlight, we are accessing a service and something goes wrong within that service, we would expect to get access from Silverlight to the error returned by the service. This way, we would have enough information to make adjustments to the service code or would know if perhaps the service was not accessible. Sadly, this is not the case. Every time a service returns a status 500 (Internal Server Error), in Silverlight, we see a 404 (Not Found), as can be seen in the screenshot below.

Silverlight says that the service can’t be found, even though we know it is accessible.

The reason for this is a limitation of the browser stack: a browser can only return to a plugin (such as Silverlight) a status 200 and 404. That means that if the state is not 200, whatever the state returned, Silverlight will see a 404. Because of this, we have no access to the service error.

How to solve things

Not all hope is lost though, there’s a solution: we can on the server change the status of the response to 200, if something goes wrong. This response is then available to Silverlight (remember, SL can only access 200 and 404) and we can thus read out the fault information within the Silverlight application.

Implementing this change of status code can be done through a service-side behavior that inspects the SOAP message and converts the status to 200. Note that it’s advised to create a specific endpoint for this purpose with this behavior if your service is going to be accessed from other clients than Silverlight!

Read more: Silverlight Show
QR:

Posted via email from Jasper-net