Page 125 - DCAP312_WEB_TECHNOLOGIES_II

Unit 6: Error Handling

Private Sub Page_Error(ByVal sender As Object, ByVal e As System.EventArgs) Notes
Handles MyBase.Error
End Sub

Or you can use this one:
Protected Overrides Sub OnError(ByVal e As System.EventArgs)

End Sub
Handling errors in these subs is a simple process. Just call Server.GetLastError to return the error.
If you want to redirect to a specific page here you can just call Response.Redirect ( “HandleError.
aspx”) or whatever your page may be. 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 its 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 does not go to the Application_Error or
customErrors) simply call Server.ClearError in this sub.
6.4.4 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, we do not handle too
many custom errors at the page 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. We will not 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.
6.4.5 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 do not 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= “status code” 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.
“Remote Only” specifies that custom errors are shown only to remote clients, and ASP.NET
errors are shown to the local host. This is the default.

LOVELY PROFESSIONAL UNIVERSITY 119