One of the tricks I've learned over time is to always set visual studio to stop on a thrown exception. Normally, during running of a .net application, unhandled exceptions are simply processed and absorbed quietly. For the most part, this is good because you do not want your users to see error messages all the time, and likely what is being thrown is not interesting anyhow. It is however bad because throwing exceptions is very time consuming for the application as well as it may actually be something important.
To keep this from happening, my "best practice" is to go into the menu choice Debug/Exceptions as follows:
“
Then, you will get the following dialog. Make sure to check everything as show below:
Then, when you hit an exception while debugging, the debugger will stop on the offending line so you can figure out if you should be surrounding this with a try/catch, or whether it's just an oversight you need to fix.
Good luck with this! It's helped me a huge amount in finding bugs I would have likely found later and much more painfully.
August 10th, 2007 at 9:22 am
I have wasted some time in the past on a similiar issue. Just like you said, I found out later and it was much more painful. I never knew about this option in Visual Studio. Thanks for sharing!!
September 24th, 2007 at 10:47 am
Your site is very helpful, and help me a lot. Thank you for such useful information.
October 5th, 2007 at 12:09 pm
There is also one more option in Visual Studio. If you have “Just My Code” option enabled, you will not see exceptions that are thrown in ASP.NET code and remains unhandled.
This is usually not important, but sometimesit causes problems. For instance, it is important to see such exceptions while troubleshooting “event validation” problems. See http://couldbedone.blogspot.com/2007/09/conditional-updatepanel-and-event.html