Replacing the Error 500 ASP Page - The ASPError Object (Page 2 of 7 )
In previous versions of ASP (prior to version 3.0, which is included with IIS 5), error handling was a tricky task.
Although JScript has structured error handling, which is in line with the latest languages via try ... catch blocks, the only available option with VBScript was to put an On Error Resume Next before a piece of code, and to then check whether an error occurred after the line using an If Err Then ... construct.
Following any error processing, error-trapping could be disabled using an On Error GoTo 0 statement. When functionality wasn't wrapped in COM components, which are largely developed using languages that support better error handling (such as Visual Basic and C++), many applications have been developed that have a single On Error Resume Next before any processing begins, with no subsequent error trapping or handling rather than trapping errors in such a time-consuming way.
With ASP 3.0, the situation changes a little, and error management becomes slightly more structured. This does not mean that VBScript has proper error handling such as an On Error GoTo Label statement, but a step has been made in the right direction with the inclusion of the ASPError object.
This object is returned by the Server.GetLastError method call, and has the following read-only public members (which are covered in more detail in MSDN):
Returns an error code generated by IIS
Returns the standard COM error code
Returns the actual source code, when available, of the line that caused the error
Indicates if the source of the error was internal to ASP, the scripting language, or an object
Indicates the name of the .asp file that was being processed when the error occurred
Indicates the line within the .asp file that generated the error
Indicates the column position within the .asp file that generated the error
Returns a short description of the error
Returns a more detailed description of the error if it is an ASP-related error
As can be seen, there is far more information available in this object than in the standard Err object -most notably, the line and column where the error occurred, and an extra description.
Whilst these details are far more useful, there is one fundamental problem; a piece of code such as the one given below will not work:
On Error Resume Next dblValue = 1/0 '== Will cause a divide by 0 error Set objError = Server.GetLastError If objError.Number>0 Then 'Do some error processing End If
Once an On Error Resume Next statement is used, no errors are raised and objError won't contain any information - the only way to test for an error would be the traditional "If Err.Number<>0 Then ..." statement.
If the On Error Resume Next line was missing, then processing would be transferred to the error page as soon as an error is encountered. This means that the only place that the error object can actually be used is on the error page itself. Control is passed to this page via a Server.Transfer() call as soon as an un-trapped error occurs. If needed, On Error statements can still be made to stop execution from passing to this page.