Error handling in ASP.NET

Overview of error handling

In ASP.NET, there are three different ways using which the errors can be handled. They are as listed below.

1. Debugging: User can set the breakpoints in the code and execute line by line code.
2. Tracing: User can trace the program at page and application level
3. Error handling: User can handle the standard and custom errors at application and page level.

Tracing

Once user has created an ASP.NET web application, it is necessary to check that the application is executing correctly and does not return unexpected results. The tracing feature helps user to enable track the program execution. User can view the information for a web page. The information contains page methods, rendering page controls, collections, etc.

Tracing is implemented in the following two levels:

1. Page Level
2. Application level

Page Level

In the page level tracing, the information is created at the end of the page rendering. The information can be page requests and responses. The issues in the web page can be detected very easily.

The following steps are included in the page level tracing of an application.

1. Add the following directive at the start of the web page.
   
   
   Code:

   <%@ Page Trace="True" %>

2. Add the Sort order for the trace messages. The TraceMode attribute is used. The messages can be traced using time or category.

The following code snippet demonstrates the trace messages based on Time.

Code:

<%@ Page Language="C#" Trace="True" TraceMode="SortByTime" %>

When user enables tracing in a web application, the following tracing information is displayed.

1. Request details: The information about the session Id, request time, request encoding, request type, etc are displayed.
2. Trace information: The information related to the performance of the web page is displayed. There are various events related to the web page and are displayed under the message column. The data related to execution time, elapsed time is displayed.
3. Control Tree: The data for every web control is displayed. The number of bytes for every control on the web page is displayed.
4. Application state: Various application variables, types and values are displayed.
5. Request cookies: Information about all the cookies is sent by the web browser with the web page request.
6. Response cookies: Information about the cookies returned by the web browser with the response.
7. Headers collection: All the headers information is displayed as the part of the request.
8. Form collection: The list of values posted back to the server is displayed.
9. Querystring collection: The values in the query string are displayed.
10. Server variables: The server variables and their values are displayed.
    
    https://www.dropbox.com/sh/begui1v50n2jbvq/AACwailO97wZ7pfXdfiGM-mXa?dl=0
    
    

2. Application level

In page level tracing, the information is displayed at the end of the web page. User needs to enable the tracing for every web page in an application. To resolve this problem, the application level tracing is used. In application level tracing, a page is used for displaying the trace values.

User must enable the application level tracing in the configuration file. Add the following code snippet to demonstrate the application level tracing.

Code:

<configuration>
    <system.web>
    <trace
        enabled="true"
        requestLimit="100"
        pageOutput="false"
        traceMode="SortByTime"
        localOnly="true"
        mostRecent="false" 
    />
    </system.web>
</configuration>

The elements used in the above code are explained.

1. enabled: It states that the tracing is enabled in an application.
2. requestLimit: The tracing information is stored for the HTTP requests.
3. pageOutput: The trace information is shown at the end of every web page.
4. traceMode: The order in which the trace messages are shown.
5. mostRecent: The recent messages are sorted. If the messages go beyond the limit, the older ones are removed.

Error handling

ASP.NET helps user to handle errors at page level and application level.

Page level error handling

User can handle the errors present in the web pages. The try catch block or the Page_Error subroutine is used for handling errors.

Try catch block

The statements that cause the errors are placed in the try catch block. The errors are handled at runtime. The code that causes the exception is placed in the try block. The exceptions are handled in the catch block. The exceptions are inherited from the Exception class.

The following properties are used for handling the exceptions.

1. Source: A string representing the methods before the error has occured
2. Message: A string representing the error message
3. StackTrace: A string representing the methods called immediately before the error occurred
4. TargetSite: The method stating the cause of the error

Application level error handling

User can handle the errors on the ASP.NET web pages. If the exception is unhandled at the page level, it is passed at the application level error handler.

The <customErrors> element is used for handling the errors in ASP.NET. The details of the error message are available using the element.

The following code snippet demonstrates the <customErrors> element.

Code:

<configuration>
<system.web>
    <customErrors mode="On" defaultRedirect="Default1.aspx" >
    </customErrors>
</system.web>
</configuration>

The attributes used by the <customErrors> element are:

1. mode: The mode for handling the custom errors. The attribute can have following values.
   • Off: The display of the custom errors is disabled.
   • On: The display of the custom errors is enabled
   • RemoteOnly: The errors messages are displayed for the remote users
2. defaultRedirect: The URL for the error messages is defined.

The following code snippet demonstrates the customErrors section in a web page.

Code:

<configuration>
<system.web>
    <customErrors mode="On" defaultRedirect="ErrorPage.aspx">
    <error statusCode="408" redirect="Timeout" />
    </customErrors>
</system.web>
</configuration>

Modify the page directive in the page level error handling.

Code:

<%@ Page Language="C#" AutoEventWireUp="true" CodeBehind="Default.aspx.cs" Inherits="error1_Default" Trace="true" ErrorPage="Page1.htm" %>

Debugging

User can view the working of the code using the step wise procedure. The complete view of the objects is possible using the debugging.

User can enable the debugging option in the web.config file in an ASP.NET application.

Code:

<system.web>
    <compilation debug="true">
    <assemblies>
    .....
    </assemblies>
    </compilation>
</system.web>

Breakpoints

The breakpoints are used to mark the point in the code. The point marks break of the execution of the code. For adding a breakpoint, right click on the code and select the insert breakpoint option.

The following figure shows the breakpoint insertion in ASP.NET.



User can disable the breakpoint by right clicking the breakpoint in an application.



User can add the condition to the breakpoint by adding an expression when the code reaches the breakpoint.



The breakpoint filter can be added to the code. It helps user specify the processes, threads, machine specification for the working of the breakpoint.



Debug Windows

There is a debug window provided by the Visual Studio application. It is useful for storing the data about the programs.

The windows provided by the application are mentioned below:

1. Watch: It is used to show the different variable sets
2. Immediate: It shows the different variables and expressions
3. Locals: The variables in the current context are shown
4. Threads: The control threads are displayed
5. Call Stack: All the methods of the call stack are shown