Blogger :
Pluralsight Blogs
All posts :
All posts by Pluralsight Blogs
Category :
XML
Blogged date : 2007 Nov 13
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.
Later, 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 a Page.xaml file that loads with the plugin – Silverlight will tell us there is a parser error. The error message tends to make one look inside the .xaml file for malformed XML. The real problem is that Silverlight can’t instantiate the object requested in XAML because the default constructor throws an exception.
Contents
ReBlogger Contents
Email TopXML