Silverlight Error Handling Default Behavior


What actually happens when exceptions occur inside the managed code of a Silverlight application can be a little confusing at first.  Factors that affect what you will see depend on:

  • Whether or not the app is being run by the Visual Studio debugger
  • Whether or not Silverlight debugging is enabled
  • Whether or not the offending code is in a try/catch block
  • Whether or not the Applicaiton.UnhandledException event has a handler
  • Whether or not the Silverlight Plug-in has an onError handler in JavaScript
  • Whether or not script debugging is enabled in IE

That’s a lot of “Whether or not”s to deal with. To try and make sense of it, I have created the following flow chart.  Be warned, this is how I see it, and what my testing has shown me.  Your mileage may vary.  Also, this all assumes that you are using Internet Explorer as the browser.  The browser portion of the following information will be different with each browser.  Click the image or link below to download a zip file with the Visio document, a PNG, and a PDF of the flowchart.

Silverlight Error Handling Default

If you have any input, drop a comment below and let me know.  As always though the files I am posting are yours to do with as you wish, I retain no rights. 

Choosing the right property type in Silverlight

If you are going to be creating your own classes or controls in Silverlight, you need to choose wisely when you implement the properties for your new class or control.

Silverlight properties can be either:

  1. Standard CLR Properties
  2. Standard CLR Properties that raise the INotifyPropertyChanged interfaces PropertyChanged event
  3. DependecyProperty instances that support a value precedence based on animation, data binding, templates, styles, and default values.

The kind of property you need to create depends a great deal on what you need to do with it. 

If you just need a place to hold onto a value, a standard CLR property will suffice. 

If you only need to provide a value in data binding, then INotifyPropertyChanged is probably the right choice.  This is the simplest way to provide value change notification to subscribers.  DependencyProperties also provide change notification, but at a much higher cost, and if all you need is the change notification piece then the DependencyProperty comes with too much extra baggage.

If you need the property to be the target of an animation or data binding, or if you want to set it’s value in a template or style, then you should implement it as a DependencyProperty. 

Property Type Choice Flow Chart

Do you have a different opinion on the above?  Tell me about it!