An error is an event; an exception is the object that the event creates. When the program flow is blocked by an error, then there should be a solution to overcome that which we could call as exception. These exceptions are classified as structured and unstructured exceptions. Error handling code block plays the vital role to eliminate those errors. All applications should have error handling. Errors will occur in our applications. We should try to trap errors. Errors are a development fact, but we should handle them gracefully.
With this in mind, we should know:
1. When an error occurs
2. Where it occurred
3. What the error is
IIS provides great error-handling capabilities.Sometimes we know an error will occur, and we can't always trap it in a nice way without overriding the site's default error redirection page. For example, upon access to a resource that requires authentication, we may need to redirect to an application's login page. Also, a very common problem exists with Web hosts. If you have a hosted Web site, you usually have no control over its IIS configuration. Thus, setting up custom error pages can be next to impossible in traditional ASP. This is elimiated with ASP.NET.
ASP.NET allows us to build Web applications with any language following the Common Language Specification (CLS). Languages following the CLS, a specification submitted to ECMA for standardization, are capable of running on the Common Language Runtime (CLR). The CLR provides features such as garbage collection, secure code execution, and structured exception handling, and more.
We can take advantage of this language-independent, structured exception handling within our ASP.NET applications. Structured exception handling is done through try/catch/finally blocks, and forces us to deal with exceptions when they occur. If an exception is raised and we don't explicitly handle the exception, a general ASP.NET exception will occur, forcing the application to terminate without allowing the code to continue executing, resulting in an error page. This makes finding errors much easier.
The concept of checking for errors still exists in ASP.NET, but we must deal with the error when it occurs:
<Script runat=server> Public Sub Page_Load(sender As Object, e As EventArgs) ... Begin Try dataObject.SomeMethod() Catch ' Looks like an exception occurred, do work to either ' handle the error and clear the exception or fail End Try ... End Sub </Script>
As we know ASP.NET forces us to deal with an exception when an error occurs. We obviously don't write Try/Catch/Finally blocks around all of our code, and in that cases where we don't, ASP.NET still provides us with some facilities for handling the exception through two events:
The case exists where an exception is unexpected and does not occur within the bounds of a Try/Catch/Finally block. These exceptions are usually an indicator that something is substantially wrong with the application. Which means some abnormal error has occurred and there is no graceful way to get out of the error. In these situations, where we don't wrap the faulty code with a Try/Catch/Finally block, we still have the option to deal with the error at either the Page or Application level.
These events are raised whenever we have an unhandled exception occur within our application. If a Page_Error event is present within an ASP.NET page, and an unhandled error occurs, the event is raised. Application_Error is slightly different. It is raised for all unhandled exceptions in our ASP.NET application and is implemented in global.asax or within an HTTP Module.
Both of these events are extremely useful since they allow us a final opportunity to execute code before sending the caller an HTTP redirect to the named ASP.NET error page.
The first line of defense in error handling happens at the page level. You can override the MyBase.Error sub as such: (Visual Studio will complete the code if you click either the Overrides or BaseClass events in the editor). The two functions you can use (one or the other, both will not work as only one will get called)
Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Error End Sub
Protected Overrides Sub OnError(ByVal e As System.EventArgs) End Sub
This method of handling errors is good for several reasons.
1. If you need to override the Application_Error or the customErrors setup in the web.config file
2. If each page must implement it's own error handling If you need to log specific information and then carry on, just code for your logging or whatever here, and that is all. If you need to cancel the error processing here (so it doesn't go to the Application_Error or customErrors) simply call Server.ClearError in this sub.
The global.asax file contains the next line of defense against errors. When an error occurs, the Application_Error sub is called. . 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.
The default settings we find when we view machine.config are:
RemoteOnly: When an unhandled exception occurs, local users will see the ASP.NET rich error page, which includes compilation details and accessibility to the full source. However, remote users are shown a different ASP.NET error page that simply lets them know an error occurred. No details are provided. If a custom error page is available, this is shown to remote users.
On: The detailed ASP.NET error page is never shown, even to local users. If a custom error page is available, it is always used.
Off: The detailed ASP.NET error page is always displayed, even if a custom error page exists.
In addition to the mode settings, there are several other configuration options for the custom Errors section of the configuration.
defaultRedirect: A custom error page that the client is redirected to when an error occurs.
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 pages 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).
customError.aspx, we can add the following configuration entry in web.config for an ASP.NET application:
<customErrors mode="On" defaultRedirect="customError.aspx"/>
Whenever an unhandled exception occurs within our application, the user is redirected to customError.aspx, which provides a user-friendly error message.
Special Case: This option provides a special case for the custom error page depending upon the HTTP status code. If we may want a custom error page if the request attempts to access a page that doesn't exist (HTTP 404). Here we can make use of another configuration element that can be nested in <customErrors>, <error> :
<customErrors mode="On" defaultRedirect="customError.aspx"> <error statusCode="404" redirect="custom404.aspx"/> </customErrors>