By default, when your web application encounters an exception it displays the ASP.NET server error page, as shown in Figure 42-3. Colloquially called the Yellow Screen of Death, this page displays the exception details including the stack trace.

Figure 42-3. Figure 42-3

The server error page is generated under both debug and normal execution. Although it is useful to have this information during development, it is not something that you should be displaying to your end users. Fortunately, there is an easy way to configure redirections for exceptions, including standard HTTP errors, by editing the customErrors section in the web.config file.

Modifying the previous web.config file to include these redirection options for 403 (access denied) and 404 (page not found) can result in a configuration similar to the following:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.0" />
        <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
            <error statusCode="403" redirect="AccessDenied.html" />
            <error statusCode="404" redirect="PageNotFound.html" />
        </customErrors>

</system.web>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true" />
    </system.webServer>
</configuration>

The mode attribute of the customErrors section defines three options for displaying a custom error page instead of the default server error page. These are:

The server error page is useful in production scenarios where you cannot run the application in Debug mode. However, when debugging, it is much more useful to break execution as soon as an exception occurs. You can do this by enabling the Break When an Exception Is Thrown option for the Common Language Runtime. Figure 42-4 shows how this option is set in the Exceptions dialog under the Debug

Figure 42-4. Figure 42-4

Once you have enabled this option, when an exception occurs, Visual Studio drops back into the IDE and positions the workspace so the statement at issue is visible. Just like Windows-based applications, Visual Studio can aid you when errors occur by displaying the Exception Assistant. As shown in Figure 42-5, web errors are fully detailed and include information about which part of the statement is in error.

Figure 42-5. Figure 42-5

You can gather additional information on the error by clicking the View Detail link, which provides you with a comprehensive exception object visualizer that you can navigate to determine the content of the error at hand.

Edit and Continue, which enables you to modify code when the application is paused in a debug session, is disabled by default in ASP.NET web applications. This useful feature can be enabled by right-clicking the project entry in the Solution Explorer and selecting Properties. Under the Web tab option page, check the Enable Edit and Continue option. This is only supported for the built-in Visual Studio development web server.

Web site projects do not support Edit and Continue, however, because they naturally support a very iterative style of development; it is not such a useful feature for those projects. Edit and Continue is explained in more detail in Chapter 40.

Although debugging your applications is indeed easy with the tools Visual Studio 2010 provides, it is always best to try to avoid error situations proactively. You can do this in web applications with structured Try-Catch exception handling, but you will also want to make your solutions more solid by including code to handle any errors that fall outside any Catch conditions.

You can catch errors on two levels — on an individual page you can intercept unexpected errors and produce a custom-built error, or you can catch errors on an application-wide level through the implementation of a routine to handle errors in the global.asax file.

Setting breakpoints for JavaScript code is no different from setting any other breakpoint. Within the editor window, any breakpoints in JavaScript code are displayed with a white circle in the center, as shown in Figure 42-6.

Figure 42-6. Figure 42-6

When the debugger hits a breakpoint, it pauses execution and displays the HTML code that has been rendered on the client, as shown in Figure 42-7. This provides a true debug experience, because it includes all client-side elements such as the ViewState and server controls rendered in HTML.

Figure 42-7. Figure 42-7

Visual Studio 2010 also has comprehensive watch visualizers for client-side elements. Figure 42-7 demonstrates this with a tooltip that shows the properties and methods of the document object.

It is also possible to set both client-side JavaScript breakpoints and Visual Basic or C# server-side breakpoints at the same time on the same page. This enables you to step through both server-side and client-side code in a single debug session.

Several scenarios exist where ASP.NET sends down to the client JavaScript that has been dynamically generated on the server. For example, the ASP.NET AJAX controls such as the Update Panel will generate client-side JavaScript files that are actually stored as resources in the ScriptManager control.

When you are running a web application in Debug mode, the Visual Studio Solution Explorer shows a list of all the script references that the page you are debugging has loaded, as shown in Figure 42-8. Double-clicking any of the links under the Script Documents node displays the JavaScript code and enables you to set breakpoints within those scripts.

Figure 42-8. Figure 42-8

ASP.NET AJAX provides both Debug and Release versions of its client JavaScript libraries. The Release version is optimized for performance and minimizes the size of the JavaScript that must be downloaded to the client. The Debug version is more verbose and provides additional debugging features at runtime, such as type and argument checking.

If debugging is enabled in the web.config file, ASP.NET AJAX uses a debug version of the client libraries. You can also enable the debug version on a per-page basis by setting ScriptMode="Debug" on the ScriptManager control.

ASP.NET AJAX also includes the Sys.Debug class, which can be used to add debug statements to your client JavaScript. This class can be used to display the properties of objects at run time, generate trace messages, or use assertions.

To implement page-level tracing, you simply need to include a trace attribute in the @Page directive at the top of the page you want to trace. A simple ASPX page with tracing activated might look like the following:

<%@ Page Language="C#" AutoEventWireup="true" Trace="true"
TraceMode="SortByCategory" CodeBehind="ShowTrace.aspx.cs"
Inherits="CSWebApp.ShowTrace" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Trace Example Page</title>
</head>
<body>
    <form runat="server">
    <div>Hello!</div>
    </form>
</body>
</html>

In addition, you can specify how the tracing messages associated with the page request should appear by using the TraceMode attribute. Set this to SortByTime to output the tracing messages in the order that they were produced, or SortByCategory to categorize them into different message types. Figure 42-11 shows the trace output for the sample page defined in the previous code when sorted by category.

Figure 42-11. Figure 42-11

Application-level tracing can be enabled through the web.config file. Within the system.web node, you need to include a trace node that contains the attribute enabled with a value of true. When using application-level tracing, you can control how the tracing is produced through the pageOutput attribute. When set to true, you receive the tracing information at the bottom of every page (similar to how it appears in Figure 42-11), whereas a value of false ensures that the tracing information never appears on the page, and is instead only accessible through the Trace Viewer (covered later in this chapter). You can also restrict the amount of information to trace with the requestLimit attribute. Including a trace node for the web.config file you saw earlier in this chapter results in a configuration like the following:

<?xml version="1.0"?>
<configuration>
    <system.web>
        <compilation debug="true" targetFramework="4.0" />
        <customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">
            <error statusCode="403" redirect="AccessDenied.html" />
            <error statusCode="404" redirect="PageNotFound.html" />
        </customErrors>
        <trace enabled="true" pageOutput="false" traceMode="SortByCategory"/>
    </system.web>
    <system.webServer>
        <modules runAllManagedModulesForAllRequests="true" />
    </system.webServer>
</configuration>
    </system.web>
</configuration>

Tracing output is voluminous. The simple Hello page defined earlier produces almost three full printed pages of information, including the following categories of data:

As you can see, when tracing is implemented for a web page or application, you gain access to an enormous amount of information that you can then use to determine how your application is performing. You can see whether problems exist in the various collections in the way of missing or extraneous data, as well as analyze the Trace Information list to determine whether there are any abnormally long processing times for any specific events.

The Trace Viewer is a custom handler included in your web application when you have application tracing activated. When tracing is being reported at the application level, you can navigate to this page and view all page tracing output as it occurs. To view the Trace Viewer, browse to the trace.axd page in the root directory of your web site.

The Trace Viewer provides a summary table of all requests made in the application, along with the time the request was made and the HTTP status code returned in the response. It also provides a link to detailed information for each request (which is the same information that you can see on a page trace discussed earlier), as shown in Figure 42-12.

Figure 42-12. Figure 42-12

You can supplement the default trace information with your own custom-built trace messages, using the Trace.Warn and Trace.Write methods. Both have the same set of syntactical overloads, and the only real difference is that messages outputted using the Warn method are displayed in red text.

The simplest form for these commands is to include a message string like so:

Trace.Warn("Encountered a potential issue")

However, you can categorize your warnings and messages by using the second and third forms of the methods, including a category and optionally an error object as well:

Trace.Warn("MyApp Error Category", "Encountered a potential issue", myAppException)