Tell the Debugger to Ignore Silverlight Validation Exceptions
Silverlight Thursday, September 17 2009I recently wrote an article that demonstrates how to use the DataForm and validate data entry in Silverlight using the DataAnnotations. One of the pet peeves I have with the validation is that it throws in exception in the setter of your public property. Putting my disagreements with that aside for a second, it causes a major inconvenience when debugging the application. For example, when running the application that uses the DataAnnotations and one of the conditions is violated, the debugger will catch the validation exception and break into the code. The desired behavior is that the debugger will not break into the code since I really just want to see the validation information on screen.
For example, the default behavior when not entering a value for the FirstName property will yield the result shown in the image below.
Yes, I can simply hit F5 and it will bypass the exception. But this gets ugly when you have more than one violation and you are testing the app. What I really want is to simply see the validation on screen, as shown below:
last night I was chatting with Jeff Handley (of DataAnnotations fame) and he mentioned a technique I was unaware of that will ignore the exception of this particular type. I was thrilled to see that it works and is quite simple to do. There is a feature in Visual Studio that allows you to do this (I love learning something new about Visual Studio). Here are the steps you need to go through to ignore the exception in Visual Studio:
1) Go to the Debug menu in Visual Studio, and select the Exceptions menu item
(If the images are hard to read, click on the images below for larger versions of them)
2) Expand the Common Language Runtime Exceptions item in the list
3) Click the Add button to add a new exception type
4) Select Common Language Runtime Exceptions from the drop down list
5) Enter System.ComponentModel.DataAnnotations.ValidationException in the Name textbox
6) Click OK
7) Uncheck the User-unhandled checkbox for the item
System.ComponentModel.DataAnnotations.ValidationException (the highlighting is mine)
8) Click OK
Now when you run your application using the debugger, the debugger will not stop no the exception. It instead will bypass those exceptions and simply display the validation information in your application. Basically skipping right to this:
Thanks to Jeff Handley for pointing this out to me!
9.17.2009 at 3:11 PM
Excellent! Thanks for posting about this. This was really bugging me too.
9.17.2009 at 11:10 PM
Is there a way to replicate this in Visual Web Developer 2008 Express?
9.18.2009 at 3:37 AM
Nice technique. I didn't know about this either.
What we've been doing is a bit more coarse grained. We decorate the property setter with an attribute that tells the debugger not to stop for ANY exception thrown by the setter.
Here's the attribute we use: [global::System.Diagnostics.DebuggerNonUserCode]
The advantage is that no one has to configure Visual Studio as you have shown here.
Another possible advantage: if you're running your code in a context where you're exercising the property outside of binding, the exception will stop the debugger THERE ... where your property is set. With the technique you've shown, I believe the debugger never stops for this exception anywhere in the call stack.
On the downside, you'll have to comment the attribute out if you actually WANT the debugger to stop inside the property setter when the validation exception is thrown.
9.18.2009 at 3:40 AM
Oh ... another big disadvantage is that you have to put that attribute on every setter. Not so bad if you're generating your properties but a real PITA if you write them by hand ... and the attribute clearly adds more noise to your code.
No ... I like this trick of Jeff's. Not sure which approach is "better".
9.18.2009 at 9:25 AM
Ward ... I don't prefer the attribute approach simply due to the added noise on the setters. In that respect, I don't like the setters at all :-) If you look at my example they are noisy enough due to the validation technique. I'd really like to get them trimmed down and have a non exception based validation scheme.
That all said, I don't have a problem with either apporach (attributes or the one I showed from Jeff H). They both are work arounds.
10.14.2009 at 1:08 PM
Hey man,
I really want to thank you about this post and all of your blog I found some useful code and information.
Simo
10.14.2009 at 8:52 PM
Thanks man, for submitting this nice article, Was kind of stuck until I saw this article.