Error Handling in ASP.NET

There are three places in ASP.NET to define what happens to these unhandled errors.

• In the web.config file's customErrors section.
• In the global.asax file's Application_Error sub.
• On the aspx or associated codebehind page in the Page_Error sub.

Error handling Events :

• On the Page itself, in the Page_Error sub
  
• The global.asax Application_Error sub
• The web.config

When an exception occurs in your application, it should be an object inherited from type System.Exception, and as such will have the following public members:

• HelpLink : Gets or sets a link to the help file associated with this exception.
• InnerException : Gets the Exception instance that caused the current exception.
• Message : Gets a message that describes the current exception.
• Source : Gets or sets the name of the application or the object that causes the error.
• StackTrace : Gets a string representation of the frames on the call stack at the time the current exception was thrown.
• TargetSite : Gets the method that throws the current exception.
  

Using the global.asax File

The global.asax file contains the next line of defense against errors. When an error occurs, the Application_Error sub is called. This location happens to be my favorite place to log errors because it is the most functional. For most of my applications in .NET, I don't handle too many custom errors at the page level. I handle them at the application level. The only two locations that actually give you access to Server.GetLastError are in the Page_Error and Application_Error subs.

After the Page_Error is called, the Application_Error sub is called. Here you can also log the error and redirect to another page. I won't explain anything else about it because it is basically the same as the Page_Error but happens to be at the application level rather than the page level.

Using the web.config File

The customErrors element of the web.config file is the last line of defense against an unhandled error. If you have other error handlers in place, like the Application_Error of Page_Error subs, these will get called first. Provided they don't do a Response.Redirect or a Server.ClearError, you should be brought to the page(s) defined in the web.config. In the web.config file, you can handle specific error codes (500, 404, etc), or you can use one page to handle all errors. This is a major difference between this method and the others (although you can emulate this by doing various Response.Redirects using the other methods). Open up your web.config file. The customErrors section uses this format:


<customErrors defaultRedirect="url" mode="On|Off|RemoteOnly">
<error statusCode="statuscode" redirect="url"/>
</customErrors>

Here is some important information about the "mode" attribute:

"On" specifies that custom errors are enabled. If no defaultRedirect is specified, users see a generic error.

"Off" specifies that custom errors are disabled. This allows display of detailed errors.

"RemoteOnly" specifies that custom errors are shown only to remote clients, and ASP.NET errors are shown to the local host. This is the default.

By default, the section looks like this when you create a Web application.