Page #51 (Chapter 6 - WebClass Debugging and Error Handling) | Visual Basic Developer[ap]s Guide to ASP and IIS

	Chapter 6 - WebClass Debugging and Error Handling
	Visual Basic Developers Guide to ASP and IIS
	A. Russell Jones


	Logging and Displaying Errors


	All this has been interesting but doesn't solve the matter of the unhelpful error message displayed by the ASP page when a problem occurs. Unfortunately, although I have a solution, it's not elegant. In most cases, you can improve the error message by using the FatalErrorResponse event to return an intelligible error message if an internal untrapped error occurs. This event functions much like VB's default failure MessageBox, except that you can override the default message and provide your own. WebClasses also provide a WebClass.Error property. This property returns an Error object with only three properties rather than the usual five—Number, Source, and Description. The easiest way I know of to see this in action is to change the case of the first two <WC></WC> tags in TestItem1 HTML template to lowercase.


	<html>

</html>


	Why this causes an error I can't explain, but it does. Figure 6.7 shows the error output of the FatalErrorResponse event after changing the tags.


	Why doesn't the FatalErrorResponse event fire if you do something like you did at the beginning of this chapter—use the Response object in the Initialize event? OK, I can rationalize that: The Response object hasn't been created yet, and that causes an error that can't be returned to the browser by the FatalErrorResponse event, because (circular logic) the Response object hasn't been created yet.


	That logic also explains the behavior of the WebClass if you place a Response .Write statement in the WebClass_Terminate event. Stepping through the program with the debugger, VB will raise Error 91, Object variable or With block variable not set, when it reaches the Terminate event. If you compile the project and run it, the FatalErrorResponse event never fires. But you don't get the ASP error, either. VB does document the error for you, though—in the Application log. Figure 6.8 shows the error from the Application log. Interestingly, VB itself apparently uses the MessageBox command internally, which the runtime engine then translates into an Application log message.


	Figure 6.8: Application log error message


	Here's the inelegant solution I promised you. This solution works only after you've compiled your WebClass into a DLL (unless you fiddle around with the ASP file that VB uses to instantiate your WebClass). Although Microsoft's documentation says that you can't add code to the ASP file, you can. If you set On Error Resume Next in the ASP file before the WebClassManager creates your WebClass, you can trap errors that occur within the WebClass, which it would normally send to the Application log.


	One more time, change the code in the WebClass_Initialize event to:


	Private Sub WebClass_Initialize()

On Error GoTo Err_Init

Response.Write "Entered Initialize"

Err_Init:

Err.Raise Err.Number, "WebClass_Initialize", _

Err.Description & "<br>Error during " & _

"WebClass initialization."

Exit Sub

End Sub


	Stop the Web server, compile the project, and then restart the Web server. If you leave your browser open between iterations of the program, it will still contain the correct URL in the address field. Don't run it yet, though. First, wrap the line in the ASP file that creates the WebClass with error-trapping code so that the last part of it looks like the following:


	On Error Resume next

Application("~WC~WebClassManager").ProcessNoStateWebClass _
"WebClassDebug.debugTest", _

Server, _

Application, _

Session, _

Request, _

Response

If Err.Number <> 0 then

Response.Write "Error #" & Err.Number & ", Source: " & Err.Source &
_", Description: " & Err.Description

End if


	Save the file and navigate to the URL for the project. This time, you should get the output shown in Figure 6.9.


	If you combine this method with some internal error trapping, you can get reasonably good error messages for debugging. I'm not advocating this as a primary method of debugging your application, but you have to admit that it's better than


	WebClassDebug error '800a005b'

Object variable or With block variable not set

/debugTest/debugTest.ASP, line 14


	It's not an elegant solution because the VB development environment overwrites the ASP file each time you run the project in design mode. So during development, the usefulness of this solution is limited to helping you discover what's going on inside the WebClass when you compile the application. After you compile the project, though, the ASP file is static (until the next compile) so this solution can work long-term to help you find problems.


	For those of you developing on servers that you can't control, it's a useful way to get most error messages back to the browser. Even more useful, you can cause the program to "switch modes" by passing a parameter in the URL. You can check for the presence of the parameter to enable debugging code that traps the error inside the ASP file. In the following example, when you pass a QueryString parameter called DebugMode with a value of True, the error handler returns messages to the browser; otherwise, they go to the Application log by default.


	If Request("DebugMode") = True then

On Error Resume Next

Application("~WC~WebClassManager").ProcessNoStateWebClass _

"WebClassDebug.debugTest", _

Server, _

Application, _

Session, _

Request, _

Response

If Err.Number <> 0 then

Response.write "Error #" & Err.Number & _

& ", Source: " & Err.Source & ", Description: " _

& Err.Description

End if

Else

Application("~WC~WebClassManager").ProcessNoStateWebClass _

"WebClassDebug.debugTest", _

Server, _

Application, _

Session, _

Request, _

Response

End If


	You can extend this as needed to help you debug your applications at runtime, but just remember that you must re-create your special error-handling code to the ASP file each time you recompile. Also remember that the development environment will overwrite the file each time you run the application in design mode.


	WebClasses do log fatal errors to the Application event log on NT. But even if you have access to the Application event log, this solution can still help, because without the extra error code, you get only the default error message.