Exception Handling in Silverlight (by George Henry)

Silverlight 2.0 presents interesting challenges to developers when it comes to exception handling. This article examines some possible and recommended approaches to meeting those challenges.

Many of the significant problems and potential difficulties that a developer may encounter with exception handling in Silverlight are not peculiar to Silverlight but relate to overall best practices for exception handling in .NET. It pays to ensure that one's foundation is firm by reviewing the copious guidance available that helps a developer to implement exception handling correctly and effectively in .NET applications in general.

For problems related to the unique characteristics of Silverlight, acceptable – even elegant – solutions can be devised using the techniques suggested in the rest of this article.

1. WCF service exceptions can present special problems since they are not propagated to Silverlight code as exceptions.

   Simple solution: Create a serializable class to carry some error information back to the client machine. (It is probably a bad idea, for security reasons, to send all of the exception information available within the service method.) Each service method can create an instance of this class and export it as an out parameter. It will then be available on the client through an EventArgs property.^1,2,3

    Expand example

    Collapse example

   public class ServiceError
   {
       [DataMember]
       public string FaultType { get; set; }
   
       [DataMember]
       public string Message { get; set; }
   }
                   

2. Use the Application_UnhandledException handler in App.xaml.cs to ensure that the Silverlight plug-in keeps running.

   In Silverlight, unhandled exceptions produce a "white screen" and force a user to restart the application. (The Silverlight plug-in stops running.) A workaround can be provided by specifying code for the Application_UnhandledException handler in App.xaml.cs that ultimately flags any exception from which the application can recover as handled. (Visual Studio 2008 actually provides such code for you, that you can customize to your needs.)^3,4,5

3. Save error information on the back-end in a database coupled with a bug tracking application.

   A wealth of technical information can be transmitted, in the hope that it will facilitate debugging. One convenient way to do this is to send exception information to a PR-Tracker exception collector project. In the case of WCF faults, potentially sensitive information can be sent directly from the service layer and correlated with contextual information sent from the client. Information about exceptions thrown on the client side can be sent entirely from the client.

   Download a Visual Studio 2008 C# project that illustrates how to do this. Be sure to read the enclosed file Instructions.txt.

4. Wrap buggy features in extension methods that handle or swallow the exceptions.

   Sometimes, features of beta software or release software that hasn't been fully "shaken down" may throw exceptions erroneously. To address problems of this type, in C# 3.0 a developer may create extension methods that catch and handle, swallow or provide transparent workarounds for the erroneous exceptions thrown by the features one wants to use. Such "ugly" but necessary code should be encapsulated away from client code. Of course, one must be sure to consistently use the extension methods instead of the methods that they wrap. Later, when the underlying bugs are fixed, it should be possible to easily do global replacements and revert to using (no longer misbehaving) methods and/or properties provided by the vendor.

    Expand example

    Collapse example

   (This example assumes that clearing a collection of items may work or it may throw an exception, apparently erroneously, for a reason that is unknown or beyond the control of our program.)

   public static bool TryClearItems(this HasItems hasItems)
   {
       try
       {
           hasItems.Items.Clear();
       }
       catch
       {
           // Swallow exception in this case because (we assume)
           // it is erroneous and intermittent.
       }
       return (hasItems.Items.Count == 0);
   }
                       

5. Wrap a buggy class in a derived class that fixes or hides the bugs (including inappropriate exceptions).

   This approach is similar to the idea of using extension methods but can get significantly more involved. It makes sense particularly if more is required than dealing with an inappropriate exception or two – i.e. there is other class functionality that you want to modify or augment. It cannot be used if the problematic class is sealed. Inheritance (this approach) and extension methods can both be useful, and need not be mutually exclusive. The pros and cons of using one technique or the other, or both in combination, must be evaluated on a case-by-case basis.

References

¹ Faults and Exceptions When Using Web Services in Silverlight 2
² How to Serialize System.Exception?
³ Please Help on Logging Exceptions from Silverlight Client
⁴ Why catch(Exception)/empty catch is bad
⁵ Silverlight Application Services - Unhandled Exception Processing