Exception Handling Techniques in ASP.NET


Desktop-as-a-Service Designed for Any Cloud ? Nutanix Frame


Exceptions or errors are unusual occurrences that happen within the logic of an application. You cannot program for every possibility; hence, they are imminent. If an exception occurs within an application, the user is presented with a yellow page that looks ugly. So, how do you deal with these situations? You use exception handling techniques in ASP.NET.


There are three ways to handle exceptions/errors in ASP.NET:

  1. try-catch block. This is also called Structured Exception Handling (SEH).
  2. Error Events.
  3. Custom Error Page.

You will look at each one of them in detail in the next sections.

try-catch Block

Enclose code that accesses files, databases, and so forth inside a try-catch block because access to those resources might be denied due to various reasons causing an exception. The third part of this block is finally. It is executed irrespective of the fact that an exception has been raised. Hence, use the finally block to complete the housekeeping jobs.

As a good programming practice, always catch specific exceptions. To view the exception types supported by the .NET Framework, use the Debug menu and select Exceptions in Visual Studio.NET.

In the following code, you try to access a table that does not exist in the Northwind database; therefore, an exception is raised. By using the try catch and finally block, you handle the exception and display a message.

   con = new SqlConnection("integrated security=SSPI;
      data source= (local);persist security info=False;
      initial catalog=Northwind");
   da = new SqlDataAdapter("Select * from TblNotExisits", con);
   ds = new DataSet();
catch(SqlException ex)
   return "Connection Unsuccessful " + ex.Message;
return "Connection Successful";

Using Error Events

There are three different error events in ASP.NET that can be used in conjunction with SEH so that all exceptions are handled and the user is presented with a user-friendly error message.

  1. Page_Error: Occurs when an error occurs within the Web page. This event is in the Web form.
  2. Global_Error: Occurs when an error occurs within the application. This event is in the Gloabl.asax file.
  3. Application_Error: Occurs when an error occurs within the application. This event is in the Gloabl.asax file.

Methods in the Server object are used to handle the exception in the error events.

  1. GetLastError: Gets the last exception that occurred on the server.
  2. ClearError: Use this method to handle the exception and stop the error to trigger the subsequent error event or display the error to the user.

In the following code, you handle the exception in all the above three mentioned events but call the ClearError method only in the Application_Error event so that the error is propogated to the above level.

private void Page_Error(object sender, System.EventArgs e)
   Exception ex = Server.GetLastError();
   Response.Write("Handled error from Page<br>");
protected void Application_Error(Object sender, EventArgs e)
   Exception ex = Server.GetLastError();
   Response.Write("Handled error from Application <br>");
protected void Global_Error(Object sender, EventArgs e)
   Exception ex = Server.GetLastError(); 
   Response.Write("Handled error from Global <br>"); 

Using Custom Error Pages

Use custom error page to handle HTTP exceptions such as page not found, unauthorized access, and so forth. You can specify custom error pages in two places:

  1. customErrors section of the web.config file. This setting specifies the application-wide error page to display for unhandled HTTP errors. HTTP errors are identified by the HTTP status code. Include the <error> tag in the customErrors to display a status code-specific error page. Does not work with .htm or .html files. Set the mode attribute to "On" to view the error page locally.
  2. errorPage attribute of the @Page directive of the Web form to display the error page for the error generated on the particular Web form.

The customsError section in the web.config file specifies the application to redirect to Error404.aspx file if a non-existent file is requested.

<customErrors mode="On" defaultRedirect="Error.aspx">
   <error statusCode="404" redirect="Error404.aspx" />

The @Page directive specifies the error page to be redirected to if an error occurs in the Web page.

<%@ Page language="c#" Codebehind="PageErr.aspx.cs"
         errorPage="Error.aspx" %>

About the Author

Rohit Kukreti

He has been in Software field for last 11+ years. Always been programming on Microsoft technologies. He started with VB, ASP and then gradually moved on to ASP.Net. C# is the preferred language for development. When not working on some piece of code he likes to play table tennis and football. He is a huge fan of English Football club Manchester United.



  • Write Error Log or Exception Log into File in C# .NET

    Posted by Rashed on 03/20/2013 05:49am

    Generally we are not interested to show any type of application error to end user. Error logs are very important for collecting all error data generated by an application. It is more useful during an early or beta release of a product. That's why it is better to store any kind of exceptions in one place. A good example about exception handling is : http://cybarlab.blogspot.com/2013/03/write-error-log-into-file-in-c-sharp.html

  • Error Event Handling

    Posted by ShaunnyBwoy on 09/01/2008 02:01pm

    I noticed that whilst you have supported the error response in the global.asax file, ASP would still overthrow the buffer and display the exception. For each of the event handlers to display the response desired, you would need to end the buffer with Response.End() to prevent ASP from overwriting the contents.

  • You must have javascript enabled in order to post comments.

Leave a Comment
  • Your email address will not be published. All fields are required.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date