Tell the Debugger to Ignore Silverlight Validation Exceptions | John Papa

John Papa

Evangelist on the loose

Tell the Debugger to Ignore Silverlight Validation Exceptions

...

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.

image

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:

image

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)

image

2) Expand the Common Language Runtime Exceptions item in the list

image

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

image

6) Click OK

7) Uncheck the User-unhandled checkbox for the item

System.ComponentModel.DataAnnotations.ValidationException (the highlighting is mine)

image

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:

image

Thanks to Jeff Handley for pointing this out to me!

tags: Silverlight
  • http://www.myosity.com Anonymous

    Excellent! Thanks for posting about this. This was really bugging me too.

  • Anonymous

    Is there a way to replicate this in Visual Web Developer 2008 Express?

  • Anonymous

    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.

  • http://www.neverindoubtnet.blogspot.com/ Anonymous

    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".

  • http://johnpapa.net JohnPapa

    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.

  • http://dotnetshoutout.com/Tell-the-Debugger-to-Ignore-Silverlight-Validation-Exceptions-John-Papa Anonymous

    Thank you for submitting this cool story – Trackback from DotNetShoutout

  • http://www.codedstyle.com/silverlight-postings/ Anonymous

    Pingback from Silverlight Postings | Codedstyle

  • http://jasper22.wordpress.com/2009/09/21/silverlight-postings/ Anonymous

    Pingback from Silverlight Postings « Jasper Blog

  • Anonymous

    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

    Thanks man, for submitting this nice article, Was kind of stuck until I saw this article.

  • http://www.surfdew.com Josh King

    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

    thank you for your post. it is very useful for me.

  • Bhaskar

    thank for giving solution. IT is very useful for me…

%d bloggers like this: