Always Set Stop On Exception While Doing Debugging in Visual Studio 2005 or 2008

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:

Debug Excetpion Menu Choice

Then, you will get the following dialog.  Make sure to check everything as show below:

Debug Excetpion Menu Choice

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.

About Peter Kellner

Follow me:


Comments

  1. Hi,
    I have the opposite problem: however I set “throw” and
    “user unhadled” visual studio 2005 sp1 always stop the
    debugger on a “throw ex” instruction in the catch
    statement. In my app these exception was trapped by a
    custom handler added with AddHandler (AddHandler
    Application.ThreadException, New
    System.Threading.ThreadExceptionEventHandler(AddressOf
    AppExceptionHandler.ManageUnhandledException)).

  2. Thanks. Somehow this option got turned off in my VS 2008 and it was really bugging me. Thank!

  3. Does anyone have the newest version of Visual Studio yet? I’ve heard great things about it.

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

  5. Your site is very helpful, and help me a lot. Thank you for such useful information.

  6. ocean2000 says:

    hi,i hope you may remember me who post a question at http://www.asp.net ,i got your reply but your post is in debug mode,am i right?
    but my problem is not on debug mode.so can you give me further suggestion?

Follow

Get every new post delivered to your Inbox

Join other followers: