Regardless of your level of experience, you will encounter programmatic errors, or bugs, that will prevent your server-side scripts from working correctly. For this reason, debugging, the process of finding and correcting scripting errors, is crucial for developing successful and robust ASP applications, especially as the complexity of your application grows.
The Microsoft® Script Debugger is a powerful debugging tool that can help you quickly locate bugs and interactively test your server-side scripts. With Script Debugger, which also works with Windows Internet Explorer version 3.0 or later, you can:
Note You can use the debugger to view scripts and locate bugs, but not to directly edit your scripts. To fix bugs, you must edit your script with an editing program, save your changes, and run the script again.
Before you can begin debugging your server-side scripts, you must first configure your Web server to support ASP debugging.
After enabling Web server debugging, you can use either of the following methods to debug your scripts:
While debugging your server-side scripts you might encounter several types of errors. Some of these errors can cause your scripts to execute incorrectly, halt the execution of your program, or return incorrect results.
A syntax error is a commonly encountered error that results from incorrect scripting syntax. For example, a misspelled command or an incorrect number of arguments passed to a function generates an error. Syntax errors can prevent your script from running.
Run-time errors occur after your script commences execution and result from scripting instructions that attempt to perform impossible actions. For example, the following script contains a function that divides a variable by zero (an illegal mathematical operation) and generates a run-time error:
<SCRIPT LANGUAGE=VBScript RUNAT=SERVER>
Result = Findanswer(15)
Document.Write ("The answer is " &Result)
Function Findanswer(x)
'This statement generates a run-time error.
Findanswer = x/0
End Function
</SCRIPT>
Bugs that result in run-time errors must be corrected for your script to execute without interruption.
A logical error can be the most difficult bug to detect. With logical errors, which are caused by typing mistakes or flaws in programmatic logic, your script runs successfully, but yields incorrect results. For example, a server-side script intended to sort a list of values may return an inaccurate ordering if the script contains a > (greater than) sign for comparing values, when it should have used a < (less than) sign.
You can use several different debugging techniques to locate the source of bugs and to test your applications.
When a run-time error interrupts execution of your server-side script, the Microsoft Script Debugger automatically starts, displays the .asp file with a statement pointer pointing to the line that caused the error, and generates an error message. With this type of debugging, called Just-In-Time (JIT) debugging, your computer suspends further execution of the program. You must correct the errors with an editing program and save your changes before you can resume running the script.
When an error occurs and you cannot easily locate the source of the error, it is sometimes useful to preset a breakpoint. A breakpoint suspends execution at a specific line in your script. You can set one or many different breakpoints before a suspect line of script and then use the debugger to inspect the values of variables or properties set in the script. After you correct the error, you can clear your breakpoints so that your script can run uninterrupted.
To set a breakpoint, open your script with Script Debugger, select a line of script where you want to interrupt execution, and from the Debug menu choose Toggle Breakpoint. Then use your Web browser to request the script again. After executing the lines of script up to the breakpoint, your computer starts the Script Debugger, which displays the script with a statement pointer pointing to the line where you set the breakpoint.
In certain cases, you may want to enable the Script Debugger Break at Next Statement if the next statement that runs is not in the .asp file that you are working with. For example, if you set Break at Next Statement in an .asp file residing in an application called Sales, the debugger will start when you run a script in any file in the Sales application, or in any application for which debugging has been enabled. For this reason, when you set Break at Next Statement, you need to be aware that whatever script statement runs next will start the debugger.
You can also add breakpoints to your server-side scripts written in VBScript by inserting a Stop statement at a location before a questionable section of server-side script. For example, the following server-side script contains a Stop statement that suspends execution before the script calls a custom function:
<%
intDay = Day(Now())
lngAccount = Request.Form("AccountNumber")
dtmExpires = Request.Form("ExpirationDate")
strCustomerID = "RETAIL" & intDay & lngAccount & dtmExpires
'Set breakpoint here.
Stop
'Call registration component.
RegisterUser(strCustomerID)
%>
When you request this script, the debugger starts and automatically displays the .asp file with the statement pointer indicating the location of the Stop statement. At this point you could choose to inspect the values assigned to variables before passing those variables to the component.
Important Remember to remove Stop statements from production .asp files.
To add breakpoints to your server-side scripts written in JScript, insert a debugger statement before a suspect line of script. For example, the following script includes a debugger statement that interrupts execution and automatically starts Script Debugger each time the script loops through a new value.
<%@ LANGUAGE=JScript %>
<%
for (var count = 1; count <= 10; count++)
{
var eventest = count%2
//Set breakpoint so that user can step through execution of script.
debugger
if (eventest == 0)
Response.Write("Even value is " + count + "<br>")
}
%>
Remember to remove debugger statements from production .asp files.
Note Do not confuse the debugger statement with the JScript break statement. The break statement exits a currently running loop during execution and does not activate the Microsoft Script Debugger, nor pause execution.
Aside from Script Debugger, a good set of debugging tips can greatly reduce the amount of time you spend investigating the source of scripting errors. Although most bugs result from obvious sources, misspelled commands or missing variables, certain types of logical and execution errors can be hard to find.
For more information about Microsoft Script Debugger, see the Microsoft Scripting Technologies site at http://msdn.microsoft.com/scripting/.