Exception Handling

In this chapter, we'll discuss how you can implement exception handling in a Microsoft® Silverlight® browser plug-in application using the Silverlight Exception Handling Application Block. We’ll also discuss how you can apply exception handling to asynchronous services. Then we’ll discuss how exception handling was applied in the Stock Trader V2 reference implementation.

Exception Handling Using the Exception Handling Application Block

The Exception Handling Application Block allows you to handle in a consistent manner exceptions that might occur in any layer of your application. The following code shows an example of how to use the ExceptionManager class to handle an exception:

try
{
    // Code that might throw an exception
}
catch(Exception ex)
{
    exceptionManager.HandleException(exception, 
        "ServiceLayer");
}

In the configuration console, you can then define how you would like to handle such exceptions, by specifying policies. This example shows how you could handle unhanded exceptions, in this case by logging the exception and displaying a friendly exception message:

Exception Handling in a Silverlight Application

Exception handling in a Silverlight application is very similar to exception handling in any Microsoft .NET Framework application. The general guidance for exception handling in a .NET Framework application also applies to Silverlight applications. There are Silverlight-specific aspects that you should keep in mind, which we will discuss next.

Global Exception Handler

Silverlight provides a convenient place for global exception handling. The Application object, located in App.xaml, raises an event if an unhandled exception occurs.

Unlike a regular Microsoft Windows® application, a Silverlight application will not automatically shut down when an unhandled exception occurs. By default, when you create a new Silverlight application, it will automatically add an unhandled exception handler for you that will report an unhandled exception to the browser. In most cases, the application will then keep running, without exiting.

This behavior is similar to that of a regular web application when an exception occurs in JavaScript. The advantage of this behavior is that the application can continue if the exception was not very serious. However, allowing the user to continue after an unhandled exception will leave the application in an unknown state. This can result in other problems such as data loss or data corruption. You should consider what the consequences would be for your application if the user were to be allowed to continue after an unhandled exception.

Handling Exceptions in Asynchronous Web Services

Because Silverlight only supports asynchronous web services, you'll have to take extra care when implementing exception handling for your services. It's usually a good idea to implement exception handling at the service boundaries, because it is likely that some service calls will fail. A small hiccup in the user's network connection can be enough for a web service call to fail. In those cases, you should notify the user and allow him to retry.

Sharon Says:

During our usability tests we found that our users like to be informed if something goes wrong. They want to know what has happened, but also what they should do to solve it. In the Stock Trader V2 reference implementation, if a call to a web service fails, we had to explicitly handle that action in our View Models. Depending on the situation, we either needed to show a message and automatically retry, or show a message that something went wrong and allow the user to retry or cancel the action.

When you're calling a synchronous method or service and an exception occurs, that exception will travel back up the call stack until you decide to handle it using a try-catch statement.

However, if an exception occurs while calling an asynchronous web service, then it is up to the proxy to raise an event or execute a callback to indicate that an exception has occurred. If you don't handle that exception, it will not bubble back up the call stack, but will immediately pass to the unhandled exception handler. So if you want to notify the view model or the view that a problem occurred, you will need to explicitly pass the error information from the service agent to the ViewModel and eventually to the view to show an error message.

If you don't handle the exception when it occurs, it will not travel up the call stack automatically, but instead will trigger the global unhandled exception handler. In the global exception handler, you are able to show a generic error message, but it is usually not possible to change the state of the UI to allow the user to retry. This chapter will give you a short introduction to the Enterprise Library Exception Handling Application Block. Since the Exception Handling block has been completely ported to Silverlight, with the exception of the Windows Communication Foundation (WCF) fault contract exception handler, this chapter will provide only a short introduction. If you'd like more information about the Exception Handling block, please read the chapter on the Exception Handling Application Block on MSDN®.

Introduction

The Silverlight Exception Handling Application Block helps developers create a consistent strategy for processing exceptions. When an exception occurs, it's very common to log the exception, wrap the exception in a different exception, or replace the exception entirely. Instead of duplicating this code throughout your application, the Exception Handling block allows you to define policies to determine how exceptions should be handled.

The following diagram shows how the Silverlight Exception Handling Application Block works:

The Exception Manager can be configured with one or more policies. A policy, which is defined by its name, can target one or more exception types. Each exception type can have one or more exception handlers, such as the log handler or the wrap handler.

For example, you could create a policy called Unhandled Exceptions, that targets all exceptions and that will first log the exception using the Log Handler and then display a user-friendly error message using a custom exception handler. You might also create a policy for your service agents, called Service Agents. This policy would target specific exceptions that might occur when accessing web services. When such an exception occurs, it might log the error message and then wrap the exception in a more generic ServiceException.

Next Topic | Previous Topic | Home

Last built: July 8, 2011