Export (0) Print
Expand All

How to: Debug ASP.NET Exceptions

This topic applies to:

Visual Studio Edition

Visual Basic

C#

C++

J#

Visual Web Developer

Express

No

No

No

No

No

Standard

Yes

Yes

No

Yes

Yes

Pro/Team

Yes

Yes

No

Yes

Yes

Debugging exceptions is an important part of developing a robust ASP.NET application. General information about debugging exceptions is at Exception Handling (Debugging).

To debug unhandled ASP.NET exceptions, you’ll need to make sure the debugger stops for them. The ASP.NET runtime has a top-level exception handler, so the debugger never breaks on unhandled exceptions by default. To tell the debugger to break when the exception is thrown, you must go to the Exceptions dialog box and select the Break when an exception is: Thrown setting for that exception.

If you have enabled Just My Code, Break when an exception is: Thrown does not cause the debugger to break immediately when an exception is thrown in system code (such as .NET Framework methods). Instead, execution continues until the debugger hits your code. Then, the debugger breaks. That means you do not have to step through the system code after an exception.

Just My Code gives you another option that can be even more useful: Break when an exception is: User-unhandled. If you choose this setting for an exception, the debugger will break execution in user code, but only if the exception is not caught and handled by the user code. This setting essentially negates the effect of the top-level ASP.NET exception handler, because that handler is in non-user code.

To enable debugging of ASP.NET exceptions with Just My Code

  1. If you want to use the User-unhandled setting, Just My Code must be enabled. For more information see How to: Step Into Just My Code.

  2. Open the Exceptions dialog box by selecting Exceptions from the Debug menu.

  3. On the Common Language Runtime Exceptions row, select Thrown or User-unhandled.

To do best practices for ASP.NET exception handling

  • Use try … catch blocks around code that can throw exceptions that you can anticipate and know how to handle. For example, if the application is making calls to an XML Web Service or directly to a SQL Server, that code should be in try … catch blocks because there are numerous exceptions that can occur.

See Also

Community Additions

ADD
Show:
© 2014 Microsoft