Overview
ASP.NET applications must be able to handle errors that occur
during execution in a consistent manner. ASP.NET uses the common
language runtime (CLR), which provides a way of notifying applications
of errors in a uniform way. When an error occurs, an exception is
thrown. An exception is any error, condition, or unexpected behavior
that an application encounters.
In the .NET Framework, an exception is an object that inherits from the
System.Exception
class. An exception is thrown from an area of code where a problem has
occurred. The exception is passed up the call stack to a place where the
application provides code to handle the exception. If the application
does not handle the exception, the browser is forced to display the
error details.
As a best practice, handle errors in at the code level in
Try/
Catch/
Finally
blocks within your code. Try to place these blocks so that the user can
correct problems in the context in which they occur. If the error
handling blocks are too far away from where the error occurred, it
becomes more difficult to provide users with the information they need
to fix the problem.
Exception Class
The Exception class is the base class from which exceptions inherit.
Most exception objects are instances of some derived class of the
Exception class, such as the
SystemException class, the
IndexOutOfRangeException class, or the
ArgumentNullException class. The Exception class has properties, such as the
StackTrace property, the
InnerException property, and the
Message property, that provide specific information about the error that has occurred.
Exception Inheritance Hierarchy
The runtime has a base set of exceptions deriving from the
SystemException
class that the runtime throws when an exception is encountered. Most of
the classes that inherit from the Exception class, such as the
IndexOutOfRangeException class and the
ArgumentNullException
class, do not implement additional members. Therefore, the most
important information for an exception can be found in the hierarchy of
exceptions, the exception name, and the information contained in the
exception.
Exception Handling Hierarchy
In an ASP.NET Web Forms application, exceptions can be handled based
on a specific handling hierarchy. An exception can be handled at the
following levels:
- Application level
- Page level
- Code level
When an application handles exceptions, additional information about
the exception that is inherited from the Exception class can often be
retrieved and displayed to the user. In addition to application, page,
and code level, you can also handle exceptions at the HTTP module level
and by using an IIS custom handler.
Application Level Error Handling
You can handle default errors at the application level either by modifying your application’s configuration or by adding an
Application_Error handler in the
Global.asax file of your application.
You can handle default errors and HTTP errors by adding a
customErrors section to the
Web.config file. The
customErrors section allows you to specify a default page
that users will be redirected to when an error occurs. It also allows
you to specify individual pages for specific status code errors.
<configuration>
<system.web>
<customErrors mode="On" defaultRedirect="ErrorPage.aspx?handler=customErrors%20section%20-%20Web.config">
<error statusCode="404" redirect="ErrorPage.aspx?msg=404&handler=customErrors%20section%20-%20Web.config"/>
</customErrors>
</system.web>
</configuration>
Unfortunately, when you use the configuration to redirect the user to
a different page, you do not have the details of the error that
occurred.
However, you can trap errors that occur anywhere in your application by adding code to the
Application_Error handler in the
Global.asax file.
void Application_Error(object sender, EventArgs e)
{
Exception exc = Server.GetLastError();
if (exc is HttpUnhandledException)
{
// Pass the error on to the error page.
Server.Transfer("ErrorPage.aspx?handler=Application_Error%20-%20Global.asax", true);
}
}
Page Level Error Event Handling
A page-level handler returns the user to the page where the error
occurred, but because instances of controls are not maintained, there
will no longer be anything on the page. To provide the error details to
the user of the application, you must specifically write the error
details to the page.
You would typically use a page-level error handler to log unhandled
errors or to take the user to a page that can display helpful
information.
This code example shows a handler for the Error event in an ASP.NET
Web page. This handler catches all exceptions that are not already
handled within
try/
catch blocks in the page.
private void Page_Error(object sender, EventArgs e)
{
Exception exc = Server.GetLastError();
// Handle specific exception.
if (exc is HttpUnhandledException)
{
ErrorMsgTextBox.Text = "An error occurred on this page. Please verify your " +
"information to resolve the issue."
}
// Clear the error from the server.
Server.ClearError();
}
After you handle an error, you must clear it by calling the
ClearError method of the Server object (
HttpServerUtility class), otherwise you will see an error that has previously occurred.
Code Level Error Handling
The try-catch statement consists of a try block followed by one or
more catch clauses, which specify handlers for different exceptions.
When an exception is thrown, the common language runtime (CLR) looks for
the catch statement that handles this exception. If the currently
executing method does not contain a catch block, the CLR looks at the
method that called the current method, and so on, up the call stack. If
no catch block is found, then the CLR displays an unhandled exception
message to the user and stops execution of the program.
The following code example shows a common way of using
try/
catch/
finally to handle errors.
try
{
file.ReadBlock(buffer, index, buffer.Length);
}
catch (FileNotFoundException e)
{
Server.Transfer("NoFileErrorPage.aspx", true);
}
catch (System.IO.IOException e)
{
Server.Transfer("IOErrorPage.aspx", true);
}
finally
{
if (file != null)
{
file.Close();
}
}
In the above code, the try block contains the code that needs to be
guarded against a possible exception. The block is executed until either
an exception is thrown or the block is completed successfully. If
either a
FileNotFoundException exception or an
IOException
exception occurs, the execution is transferred to a different page.
Then, the code contained in the finally block is executed, whether an
error occurred or not.
