Program debugging-Discovering and handling errors

Program | error

After reading the above, the reader must be very interested in creating an ASP page without errors. But you may find that the Web page does not work. What to do, only to test. In this section, start with a brief look at some of the tools that make debugging easier. Microsoft Script Debugger is trying to improve debugging support tools to the level of most traditional programming environments, such as Visual Basic, Delphi, and Visual C + +. However, some of the more traditional techniques that will help you track the errors that appear in the Web page are discussed here first.
7.5.1 Conventional 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.

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:

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:

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 script debugging is enabled, the script debugger starts automatically when an error occurs in the Web page of the virtual application. You can also manually launch the script debugger, in the Windows 2000 Start menu (programs| accessories| Microsoft Script Debugger). Correspondingly, you can insert a stop statement into the ASP program where you want to open the Script debugger, and when you run to the Stop statement, IIS terminates the execution of the ASP program, launches the Script debugger, displays the current page, and indicates the current line that contains the stop statement.
The Script Debugger completes the following tasks:
· View a list of documents that are or are already running, and select one to view or edit.
· A new breakpoint is set on the open Web page, and the page stops running at that point for debugging.
· Single-step debugging, one-step running of a statement, optionally executing subroutines and functions.
· View the call stack, which displays nested programs or functions that are invoked at that point in the program.
1. Tips and tricks for scripting debuggers
Here are some tips to help you find errors in your script when you use Microsoft Script Debugger.
· If you are debugging a server-side script, enable the Script Debugger for your ASP application. Otherwise, the error message is passed as text to the client's browser, and the script Debugger cannot be used on the server-side script.
· When debugging is complete, turn off debugging, or it will degrade server performance, and the wrong pages will stay on the client.
· For one or more ASP applications, if the Script Debugger is enabled, it will be routed to all of its server errors, including those that occur when the remote client accesses the Web page. Therefore, do not enable the Script Debugger unless you can debug it on your own server.
· If you are working in a browser that is not installed on the server and an error is displayed in the Web page, the error is in the server-side script. If an error message appears in the dialog box, the error is in the client script.
· If you have a syntax or run-time error in an. asp file, and you have enabled debugging for this ASP application, the client browser will not display a syntax error (unless the browser is running on the server), displaying only timeouts or unable to open the Web page.
· In a message indicating whether there is an error in the server-side script, the line number displayed refers to the corresponding line of the. asp file that contains the error.
· If there is an error in the client script created by the. asp file, the line number does not point to the error row of the. asp file, but to the HTML output line of the. asp file where the error occurred. To view this line, you should view the source program for the HTML file in the client browser.
· VBScript and JScript error codes are in Appendix D.

7.5.3 get ASP's Help and support
If you encounter an unhandled error, or something that looks like a "bug" in ASP, it's best to ask for help to solve the problem. There are a lot of useful sources of information on the web for ASPs, and we've listed a lot of them later in the 1th chapter. However, some more direct help is really needed for some special problems.
The ASP and IIS documentation installed on your computer is a good starting point and can be accessed through the URL of the browser for http://yourservername/iishelp/. When you run the additional component settings for Windows 2000 or the main Setup program (depending on the version of Windows 2000 that you installed), you should ensure that all documents are installed.
You can also get a full Platform SDK from Microsoft for Windows 2000, which contains a wealth of additional information about Internet services in Windows and Windows 2000. It contains the full VBScript and JScript references. It is available from Microsoft and is available to MSDN members. The script reference document is available separately or can be downloaded from the "http://www.microsoft.com/scripting/" Web site. You can also get the script debugger from here.
The Microsoft Developer NETWORK,MSDN Web site also provides a lot of support and help, even if it is sometimes difficult to find. You can also start with the Workshop Web site (http://msdn.microsoft.com/workshop/), which has a good index and a series of headings in the left-hand navigation bar.
In addition, the main MSDN library in http://msdn.microsoft.com/Library/default.htm contains articles, basics, FAQs, and other support materials for IIS and ASP, and the left window uses a Java Extended list control. The user is easy to find.
If you need special help, or if you need to ask some questions to other developers, there are a few useful newsgroups on the msnews.microsoft.com web site. You can also subscribe to Microsoft.public.inetserver.iis, Microsoft.public.inetserver.activeserverpages and Microsoft.public.inetserver.iis.misc. Some ASP sites also provide discussion topics, forums, or chat rooms about ASP.

7.6 Summary
This chapter discusses what most programmers do not love. Even the simplest script will not work correctly for the first time. As the ASP provides more and more features, there is an increased chance of errors in the script. It is necessary to understand how to discover and handle the basic knowledge of errors.
By analyzing the different kinds of errors that may occur, the mechanism of the default ASP and scripting engine error-handling systems to catch errors is understood to prevent errors and invalid data from being transmitted to other applications. The fewer errors that occur when programming, the easier it is to discover and resolve them.
However, good programming habits do not prevent certain kinds of errors from occurring, such as those caused by external resources and services. This means providing your own custom error-handling code, which is important to know how to track errors and handle them properly when there is an error.
Finally, an elaboration of the Microsoft Script Debugger concludes this chapter as a useful tool to help find and resolve run-time errors in your Web pages. It suspends program execution and stepping, while also being able to observe what the program is doing, and even to interact with the script.