Silverlight 1.1 Alpha – An Appetite for Exceptions

Wednesday, November 14, 2007

The current Silverlight 1.1 alpha will eat exceptions. I’m not sure if the final version will behave similarly, but if you are working with the alpha don’t let this behavior surprise you.

For example, consider the following event handlers that listen to a shape’s mouse events:

void _box_MouseLeftButtonDown(object sender, MouseEventArgs e)

{            

    throw new NotImplementedException();

}

void _box_MouseLeftButtonUp(object sender, MouseEventArgs e)

{

    _box.Width += 5;

}

The left mouse button goes down and … nothing happens. There is no indication of an error.

When the left mouse button goes up … the shape will grow in size. Silverlight is still running with the attitude of a Broadway director. Despite the setback - the show must go on.

If you have some mysterious behavior and are not catching exceptions inside event handlers, a good start might be to go into the Visual Studio Exceptions dialog (Debug -> Exceptions) and configure the debugger to break as soon as code throws an exception (the default setting is to only break on a user-unhandled exception). This might help locate the problem.

There is one area where an unhandled exception will stop the show. Consider the following user control:

public class ColorfulSlider : Control

{

    public ColorfulSlider()

    {

        // code ...

        throw new InvalidOperationException("something went wrong...");

    }

}

If we place this faulty user control into the Page.xaml file that the plugin loads – Silverlight will tell us there is a parser error. This tends to make one look inside the .xaml file for malformed XML, when in fact the problem is that Silverlight can’t instantiate the object requested in XAML because of an exception throws from inside the default constructor.

All My Pluralsight Courses

OdeToCode by K. Scott Allen