Programming | Advanced 7.5.1 General Debugging Technology
In chapter 2nd, you've seen how to use the Response.Write method and the request collection to display the contents of the collection. If the code wants to use the value from the request, the first thing to do is to ensure that the desired value exists. A problem that can easily occur is the name of an HTML control in a misspelled or changed <FORM> Web page, or a client that appears incorrectly when a query string appended to the URL is created.
1. Display various collection contents
When a program tries to run with a user-supplied value, it may not get the desired result or any results. Remember that referencing a value that does not exist in the collection of the Request object (for example, when there is no control named "ThisControl" on the form, using Request.Form ("ThisControl") does not cause an error. The result may only be an empty string. This can also happen if you expect to find values stored in a user's session object or global Application object variable.
If you create a page that displays the contents of the contents and Staticcontens collections of all request objects, sessions, and application objects, you can access them by any Web page using Server.Execute. All you need to do is add the following line to the ASP page to display the entire contents of the collection. Of course, depending on where the file resides on the server, you must set the path to the file.
<% Server.Execute "/path_to_file/debug_request.asp"%>
This is a good way to ensure that any values we want to find in the request, session, and application collections do exist and contain the appropriate values. A corresponding file, named Debug_request.asp, is provided in the CHAPTER07 subdirectory of the sample file in this book. It is essentially a combination of the Show_request.asp page for chapter 2nd and the Show_application.asp and show_session.asp pages for chapter 3rd, but some of the HTML program code is removed. It simply iterates through the collection and places the value on the current page.
You can view this page by running the Custom Error page instance. This example is seen earlier in this chapter, select the Display Debugging information check box when you open it, or open it directly in the main Menu page in the Chapter07 directory.
2. Show Middle Value
The second way to view a run in a Web page is to display the value of a Web page run-time variable. When it is possible to know where the error comes from and which variable is at work, this traditional technique cannot be discarded. However, the use of this technology is difficult due to the changes in the caching of IIS 5.0 Web pages.
In previous versions of ASP and IIS, the page buffering was turned off by default, and almost no one thought to open the buffer (open using Response.Buffer = True) unless you wanted to use Response.Redirect to complete the redirection of the page (see chap. 2nd). When responding to multiple requests, the buffer reduces the number of transitions between pages, increasing the efficiency of IIS.
However, when a run-time error occurs that stops the run, IIS automatically calls the Response.Clear method, and then calls Server.Execute to mount the custom error page, so any output that is written to the page is lost. The workaround is to temporarily add the following line of the program:
<% Response.Buffer = False%>
This program line is placed at the top of the page < @LANGUAGE ...> instruction, and any debug output generated by the Response.Write statement appears at the top of the custom error page. Remember to remove the page after you finish debugging it.
It is sometimes useful to force the program to run through an error point and then display the value of the suspect variable. Simply add the On Error Resume Next statement near the beginning of the page, and then access the Err object (in VBScript) and display the error number, error source, and description.
3. Check Item Property values
If you are using a component that has properties set in ASP script code, you can track the error by displaying all properties (or only suspicious properties) after the setting is complete and before and after the Assembly method is invoked. When a method runs, it may be found that the property value was accidentally changed by the component, either intentionally or because of a flaw in the component. Do not personally check the actual code, do not make any assumptions.
7.5.2 Microsoft Script Debugger
When developing more complex applications that work with actual tasks, it is often necessary to have a more powerful tool for debugging. The Microsoft Script Debugger (Microsoft Scripting Debugger) is a debugging tool that allows you to debug scripts that run on both client and server. It can be used for any program written by ActiveX-enabled scripting languages, including VBScript and JScript, and can be used to debug calls to Java applets, Java beans, and ActiveX components.
Before studying the tool, let's briefly explain some of the issues. As mentioned earlier, the ASP application consists of two kinds of scripts, one is client script, the other is server-side script. Client script typically consists of VBScript or JScript script statements that appear in an HTML page when they reach the client and are executed here, either when the document is loaded or in response to some events. Server-side scripts are also typically made up of VBScript or JScript statements. When the browser requests a Web page, the server-side script is executed by IIS. In the following discussion, the method for server-side scripting debugging is discussed. However, many of the techniques discussed are also available for client script debugging.
1. Server-side debugging
To debug a server-side script, run the Script debugger on the computer that is running IIS, but you must enable debugging before using the Script Debugger. For optimal performance, ASP-based applications turn off debugging by default.
Note that you do not turn on debug functionality for productive applications, that is, public Web sites that are active and are used by others. This slows down the entire application, and errors can cause the Web page to stop running in an indeterminate way.
Debugging can only be set for a virtual application and an entire Web site, to enable debugging, open the Properties dialog box for an application or site, and in the Home Directory tab, click the Configuration button, in the application Configuration The App Debugging tab of the dialog box, select Enable ASP server-side Script Debugger, as shown in Figure 7-22. The following is ready to debug our application.
Figure 7-22 screen with debug enabled
Note The Application Configuration dialog box contains a check box to enable client script debugging. This is not implemented in IIS 5.0 and is only marked as "Reserved for future use" in the document. If the usual 500-100.asp custom error page is not available, the Script error Messages section contains the text.
(1) Processing server scripts
Unlike client-side scripting, ASP-based application scripts are not event-driven. When a client requests a Web page from the server, the server reads the content of the Web page and processes all server scripts (that is, everything in the <%...%> and <script runat= "server" ></SCRIPT> section), Also included in the "in-line" script segment in HTML text, for example:
The valve of the result is: <% = strresult%>
The processing flow is shown in the block diagram shown in Figure 7-23:
Figure 7-23 Server script run flowchart
When IIS loads a Web page, it processes all the scripts in the ASP page, and before any output is sent to the client, the ASP and the script engine can catch syntax and run-time errors (unless you turn off buffering or invoke the Response.Flush method).
(2) Help provided by the Scripting debugger
When you enable script debugging, if an error occurs, you can see a dialog box that describes an ASP code error on the Server screen, click OK, and then transfer to a read-only copy of the current ASP Web page, the Script Debugger opens, and the line of error appears indicated by arrows, as shown in Figure 7-24:
Figure 7-24 Script Debugger
Here, the error arises because the name of the page Counter object method is wrong, and should be pagehit instead of dopagehit. At the same time, the Script debugger finds the error and terminates the page's operation, and the buttons on the toolbar are used to continue the program, step through the program, or terminate the processing of the page.
The button at the far right of the toolbar opens the Immediate window in the script debugger that you can use to interact with the page and is likely to find the wrong place. For example, you can query or set variable values or component properties, you can perform internal functions and subroutines, custom functions and subroutines, and object methods that have been created. In the diagram, you call the PageHit method of the page counter component, and then query the Hits property to get the value at that point in the running script.
To understand why the script debugger should not be used on a "public" site, you can open a page that contains server-side errors from the client computer. In this case, the error message dialog box appears on the server, and the Script Debugger opens on the server. On the client computer, the page is not loaded until the script debugger that is running on the server closes.
(3) Starting and using the debugger
When you enable script debugging, when an error occurs on the Web page of the virtual application, the Script Debugger automatically
[1] [2] Next page
