通过

How to Stop on First Chance Exceptions - Visual Studio .NET 2003

  • 项目

Last week, I talked about what first chance exceptions are and mentioned that you could configure the Visual Studio debugger to allow you to debug them.

Using Visual Studio .NET 2003, you can configure how the debugger handles first chance exceptions on a per exception basis or for exception families (by namespace and/or runtime). 

Here's how you enable a specific exception to be caught.  I will use System.ApplicationException in this example.

  • Start Visual Studio .NET 2003 and load (or create) a project
  • On the Debug menu, select Exceptions (or use Ctrl+Alt+E from the keyboard)
  • Expand the Common Lanugage Runtime Exceptions node in the list
  • Expand the System node
  • Select System.ApplicationException in the list
  • In the area labeled When the exception is thrown (below the list), select Break into the debugger
  • Click OK

Typically, the default value for "when the exception is thrown" (aka first chance exceptions) is "Continue".

To enable an exception family is just as easy.  This example will enable stopping on first chance exceptions for exceptions defined in the System.Net namespace.

  • Start Visual Studio .NET 2003 and load (or create) a project
  • On the Debug menu, select Exceptions (or use Ctrl+Alt+E from the keyboard)
  • Expand the Common Lanugage Runtime Exceptions node in the list
  • Select System.Net in the list
  • In the area labeled When the exception is thrown (below the list), select Break into the debugger
  • Click OK

Note: When enabling for an exception family, specific exception settings override the family level setting.  If you are not catching the desired exception, check the configuration for the exception using the first set of steps above.  Change the option to "Use parent setting" and the specific exception will inherit the family setting.

As mentioned in last week's post, if your code does not handle the exception, the debugger will typically stop with an unhandled exception and allow you to debug where you failed to catch.  Using today's tip, you can debug at the point of the throw and examine the conditions which caused the exceptional situation.

Enjoy!
-- DK

Disclaimer(s):
This posting is provided "AS IS" with no warranties, and confers no rights.

Comments

  • Anonymous
    July 19, 2005
    Yesterday, I talked about how to enable stopping in the debugger on first chance exceptions when using...
  • Anonymous
    July 20, 2005
    The comment has been removed
  • Anonymous
    July 20, 2005
    Phillip, The changes you make to the debugger's exception handling is on a per project basis. When you save the project, these changes should also be saved. If this same behavior occurs in Visual Studio 2005 beta 2, please report it via the Product Feeback Center (http://lab.msdn.microsoft.com/productfeedback).

    Thanks!
    --DK
  • Anonymous
    July 22, 2005
    Since last night (Thursday), my smartphone has, literally, been my conduit to the world; I had to drive...
  • Anonymous
    July 22, 2005
    <P>hi i have first-chance exception in my program in both debug and release module. the wield thing is this exception only happen in my machine, if i copy the whole project to other machines, and recompile, there is no such problem!!!!(drive me craze) can u tell me some possibilities about such situation? thanks [Edit: email address removed]</P>
  • Anonymous
    July 22, 2005
    Fish, first chance exceptions do not necessarilly indicate a problem in the application. If you configure Visual Studio to stop when the exception is thrown, you may be able to determine why it is occuring on your specific system.
    -- DK
  • Anonymous
    July 29, 2005
    A few days ago, I posted on how to configure the debugger to stop on first chance exceptions in Visual...
  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/716230-first-chance-exception