(ARTICLE) Exception Handling Techniques in 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: Code: <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>
The major difference is that we now handle the exceptions using Try/Catch/Finally exclusively. This is a good thing. When an error occurs, we get an instance of exception or possibly a derived, more specialized instanced, such as a NoNullAllowedException when we are attempting to insert a null value into a SQL table row that does not allow null value. Exceptions provide us with detailed information about what occurred.
Unhandled Exceptions
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: • Page_Error • Application_Error Page and Application Error Event Handlers 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.
Using the Page_Error or OnError sub
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)
Code:
Private Sub Page_Error(ByVal sender As Object, ByVal e As
System.EventArgs)
Handles MyBase.Error
End Sub
Or you can use this one:
Code:
Protected Overrides Sub OnError(ByVal e As System.EventArgs)
End Sub
COURTESY:www.go4expert.com
