Tell the Debugger to Ignore Silverlight Validation Exceptions
posted by John with 12 comments
I 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!
Anonymous on said:
Excellent! Thanks for posting about this. This was really bugging me too.
Anonymous on said:
Is there a way to replicate this in Visual Web Developer 2008 Express?
Anonymous on said:
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.
Anonymous on said:
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".
JohnPapa on said:
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.
Anonymous on said:
Thank you for submitting this cool story – Trackback from DotNetShoutout
Anonymous on said:
Pingback from Silverlight Postings | Codedstyle
Anonymous on said:
Pingback from Silverlight Postings « Jasper Blog
Anonymous on said:
Hey man,
I really want to thank you about this post and all of your blog I found some useful code and information.
Simo
Anonymous on said:
Thanks man, for submitting this nice article, Was kind of stuck until I saw this article.
Josh King on said:
I’m getting an unhandled exception debug prompt when it hits my validator, even when I have that debug error turned off. I’m thinking something must be wired incorrectly, but I have the Notify and Validates properties set to true on my TextBox control. Has anybody encountered this before? Thanks
Sakkaravarthi on said:
thank you for your post. it is very useful for me.