9.5.1- The GetLastError Method

<< 9.5.0- The Server Object's Role in Debugging

Chapter9

9.6.0- Summary >>

The GetLastError Method

You can use this method to discover details about the last error that occurred. This method then returns an object in its own right, called ASPError. It is used like this:

 

Set objASPError = Server.GetLastError()

 

The objASPError variable now contains an ASPError object and you can query its different properties and methods. This is something new that has only been introduced with ASP 3.0, and we'll talk about it in more detail in a moment. But, what did developers use before this object?

The VBScript Err Object

Before ASP 3.0, the object that you could use to help debug programs in VBScript was the Err object. It is still present in ASP 3.0 and contains information about run-time errors, but it has only got five properties:

 

• Description is the descriptive text of the error
• Number is the error number
• Source identifies the object or application that originally generated the error
• HelpFile identifies the help file associated with the error
• HelpContext identifies the Context ID in the help file, for a particular error

And two methods:

 

• Raise, to raise an error of your own
• Clear, to clear the properties

 

And that's all there is to it. It isn't particularly detailed, but the advantage of it was that it's easy to use. You can suppress errors using the line On Error Resume Next, which tells the server to carry on reading the script, even if it comes across any more errors. This requires that you do your own error handling, and provide more detailed information, if you think it necessary.

 

This of course means a lot of extra work for ASP developers who have grown complacent from a lifetime of Visual Basic or Visual C++, and are used to all sorts of weird and wonderful tools for deconstructing and recompiling their code to get to the source of an error. So, you'll be glad to find out that ASP 3.0 finally adds the error-handling capability that developers have been crying out for, for a long time. It comes in the form of ASP's very own error object.

The VBScript Err object will still work, but a more comprehensive error object has been introduced with ASP 3.0 that works in a different way to the Err object.

The ASPError Object

To help debug your code, the ASPError object has a far more comprehensive set of properties than the humble VBScript Err object:

 

• ASPCode: Returns the ASP error code
• Number: Returns the COM error code
• Source: Returns the portion of code that caused the error
• Category: Returns whether the error was caused by the script, by the object or by ASP itself
• File: The name of the file in which the error occurred
• Line: The line number of the script on which the error occurred
• Column: The column position within the file where the error is located
• Description: A short description of the error
• ASPDescription: When ASP has raised the error, this returns a more detailed description of the error

 

In fact the ASPError object also does a lot of the dirty work for you. If you've generated an error in your scripts then you've probably already used it by now. You can use this tool more effectively if you understand what ASP is actually doing when an error is generated, so let's take a quick peek into this murky world and find out what actually goes on when you generate an error. Here's a very simple program with a very simple bug:

 

<%

  for intLoop = 1 to 5

  Response.Write intLoop

  Nxt  'Error is on this line

%>

 

It's fairly obvious that we've missed out an 'e' in Next, but what does ASP do once it comes across the error? Of course, it displays a familiar The Page Cannot be Displayed message. However, if you scroll down to the foot of the screen, you'll find valuable extra information:

 

If you've used ASP 2.0 at all, then you'll know that you're now getting a lot more information than you used to. All this extra information is actually generated by the ASPError object. What happens when an error is generated? Well, ASP is told how to handle each type of error by the Custom Error dialog in IIS 5.0. For each type of error (denoted by the number of the error) that ASP encounters, you can use this dialog to instruct ASP to do one of three things. It can:

 

• Throw up the standard, unhelpful "There has been an error" message
• Redirect the user to a HTML file, which contains more details about that type of error
• Redirect the user to a URL, and then execute the ASP file (or whatever else is found there)

 

In the previous example, ASP actually performed the third of these options. You can check this for yourself, as follows. Start up the Internet Service Manager/MMC console and highlight the Default Web Site node in the left-hand box:

 

 

Go to the Action menu and select the Properties option then, when the dialog appears containing many tabs, select the Custom Error tab. From this dialog you can control what page ASP will display for each of the many possible different errors you may encounter. If you scroll down the dialog you'll see references to all of the major errors, such as HTTP 404 (page not found) or HTTP 403 (access to the page is forbidden). If you check our previous example, you'll see that this was the type of error generated was HTTP 500.100. In general, any errors that are generated within the script on your page are going to fall under the header 500, which you will find is an Internal Server error (if you look it up in Appendix G)

 

An Internal Server error indicates that a program running on the server (not necessarily an ASP script, it could just as easily be CGI or another similar type of application) has encountered an error. The subdivision 100 is used to indicate, more specifically, that the ASP itself has generated an error. In which case the standard behavior set up in the Custom IIS error dialog is to transfer you to the URL indicated:

 

 

Of course, an Internal Server error isn't a particularly informative response for the average ASP developer. Usually, something more detailed is required. The page 500-100.asp is a standard page stored in C:\Windows\help\iishelp\common and looks after ASP-generated errors. It deals with pretty much every eventuality that a script can throw up, using the properties available. However, there's nothing to stop you replacing these pages with your own web pages, which can then utilize the Server.GetLastError properties to provide more effective error notification.

Using Server.GetLastError

One upside/downside (depending on how you look at it!) is that you can't turn off error handling and use the On Error Resume Next statement to handle errors found in the ASPError object, as you could with VBScript Err object. Consider the following code:

 

<%

On Error Resume Next

Dim arrHello(3)

arrHello(5) = 6  'this line has the error: index/array size

Set objASPError = Server.GetLastError()

Response.Write "<BR>VBScript Error: " & Err.Description

Response.Write "<BR>ASPError Object Error Number: " & objAspError.Number

%>

We've generated a quick error by trying to assign a value to an array outside its previously specified dimensions. The On Error Resume Next statement, as we mentioned earlier, would automatically tell ASP that, even if it did find any errors, it should just go on to the next line as though nothing untoward had happened. Under this scheme, you wouldn't generate an error by executing his code.

 

The idea was that you could then use the VBScript Err object to pick up any errors that had occurred. You could then return and deal with them separately, as indeed you still can. However, when you create an instance of the ASPError object, you have to go to the default page (500-100.asp or your own web page) to populate the ASPError object. If you use Server.GetLastError(), after On Error Resume Next, it won't pick up any errors and the ASPError object will be empty – just as if no error had occurred. So if we run our above program, this would be the result:

 

 

As you can see from the screenshot, we return the contents of the VBScript Err object's description method, which contains the message Subscript out of range, but the contents of the ASPError object's method is equal to zero, which is the code used to show that no error has occurred.

 

What is the long and short of this then? Well, if you want to create your own customized error handling web page you need to go to the Custom Error dialog and reroute it, with the methods described earlier, to your new URL (if its an ASP) or file (if its an HTML page). You can't just stick Server.GetLastError in your own page and expect it to pick up error information – you have to have been redirected to a page by the Custom Error dialog. Thus, if you do change error handling and redirect ASP to your own custom page, just remember that you are changing the error handling for all errors generated in ASP. So please take care!

<< 9.5.0- The Server Object's Role in Debugging

Chapter9

9.6.0- Summary >>