How To Handle Errors While Developing ASP.NET Applications

Design of web-based applications needs to address to issues like scalability, security, reliability, performance, extensibility, etc. ASP.net provides a right platform to cater to the above needs. ASP.net is a part of .Net framework that works with IIS (Internet Information Server) to provide dynamic content creation on a web server when they are requested over HTTP. Leveraging on the power of .Net framework, it is used to create web-based applications in a faster and simpler way.

Some of the main features added to ASP.net from ASP, its earlier version (before existence of .Net) includes:

• Better language support (usage of languages other than VBScript, Jscript, etc.) and hence better performance

• Access to all controls on a page with support for events like load, click, etc.

• Easy deployment and configuration with high scalability

Designing a suitable strategy for handling errors gracefully is a challenge since it involves maintaining the security and reliability of the system. Error or exception is a state when the executing code cannot proceed further due to exceptions thrown by database, ASP.net runtime, third-party software, etc. By default, ASP.net runtime displays the yellow screen indicating the error information. Although it is useful in a developer environment, it cannot be directly used for the production-ready systems since it is meaningless for a user to know some unnecessary error information.

Following are the three methods for handling errors in ASP.net:

• Structured Exception Handling method
• Error handlers based on events
• Custom error page

Structured Exception Handling method

ASP.net offers structured exception handling mechanism by providing ‘Try..Catch..Finally’ blocks wherein the main code for the application logic is within the ‘Try’ block while the ‘catch’ block contains the routine to handle the exception. On occurrence of an error, an exception object is thrown by the runtime and the control of execution goes to the ‘Catch’ block in which the exception is caught to get the complete information about the exception and handled accordingly. Exception information include code location, type, reason for exception, etc. ‘Finally’ is the block for executing the code that need to be executed whether there is exception or not(usually housekeeping code like memory cleanup).

Syntax for using this exception handling method is as below:

Try{ //code underlying the business logic including exceptions thrown by user
}
Catch{ //code to catch exceptions
}
Finally{ //code after execution with/without exception
}
This method should be used in the following scenarios when:

• the executing code can result in an uncontrollable state (like opening a database, internet connection, etc.)
• there is an alternate path of execution after the error occurs
• there is a need to catch certain exceptions and handle them based on their type since it causes performance overhead
• a rectifiable error occurs and hence the user can continue to use the application after the correction

It is better to centralize exception handling as this gives a consistent behavior throughout the application.

Error handlers based on event

The two levels in which event can be handled are Page level and Application level. As the name implies, errors are handled at the Page and Application level respectively.

Page level error handler is called when the exception raised is not handled in any Try..Catch blocks or any other routine in that page. During this error, there is no access to any controls since they do not exist and hence care should be taken to not to access them in the error handler. Code for Page level handlers is within Page_Error method in the .aspx file. It is mostly used when there is a need to handle error at that stage by logging error and provide user meaningful information that is relevant for that context.

Application (or Global) level error handler is called when the exception raised is not handled in the page wherever the error occurred. Code for Global error handler is within the global.aspx file. For execution of this handler, Server.ClearError() should not be called at the page level or any other method earlier. Also, global handler will not be called for errors that cannot be detected by ASP.net runtime. Mostly, it is used when there is a common action (like logging errors, sending mail, etc.) that needs to be taken for certain type of errors.

Custom Error page

ASP.net provides a simple way to gracefully handle errors by allowing to use custom error page. By displaying the default error page (as sent directly by the server) to the end user, it confuses the user more and results in more support calls. Also, it may sometimes display sensitive information (like password for opening database) and affect the security of the system.

Error pages are mainly designed for user-friendliness (during production time) or for debugging purposes while developing the web application. By setting the following section in web.config file, the Internet information Server displays the custom error page on error (instead of the default page)
<customErrors mode = “On” defaultRedirect= “MyErrorPage.aspx”>
</customErrors>

Make sure that the custom error page is accessible by public and available for all users. Error numbers can be configured and mapped to their corresponding error pages in the web.config file so that context-sensitive error pages are displayed in a user-friendly manner.

Thus, the order of propagation of exception handler can be represented as below:

Structured Exception Handler -> Page level handler -> Application level handler -> Custom Error page.

Basic rules that need to be followed

• Restrict the display of detailed error information to only local users of the application

• Do not clear the error (by calling Server.ClearError) until you are sure that the error is handled completely and no need for accessing the error details further. However, after handling error, call Server.ClearError to proceed further.

• Log errors during exceptions caused due to failure in business critical events. Also, while logging the exception details, care should be taken to avoid updating sensitive information. .Net offers Health Monitoring service with logging facility that can be made use of.

Thus, ASP.net provides multiple options for handling errors in a web-based application to make it more robust, reliable, secure, consistent and user-friendly.

|Designing applications in .Net using Service Oriented Architecture | How to Create and Use Anonymous Delegates in C# (C Sharp) |How to Define Custom Attributes in C# (C Sharp)| How To Handle Errors While Developing ASP.NET Applications | How to Use Indexer in Classes and Interfaces of C# (C Sharp)| Illustration of Access Keywords (base, this) with Examples in C# (C Sharp) | Illustration of Null Coalesce Operator (??) in C# (C Sharp) |Indexers Vs Properties in C# (C Sharp) | More about Reserved Attributes of C# (C Sharp)| Overview of Unified Type System of C# (C Sharp) | Purpose of Delegates in C# (C Sharp) |How does Simple Object Access Protocol (SOAP) help in Internet Communication |How to Create and Use Anonymous Delegates in C# (C Sharp)|