Regardless of your planning or level of experience, script errors, or bugs, may initially prevent your ASP server-side scripts from working correctly. This means that debugging, or the process of finding and correcting scripting errors, is crucial for developing successful and robust ASP applications.
The Microsoft® Script Debugger is a powerful debugging tool that can help you quickly locate bugs and interactively test your server-side scripts. With the 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.
(This feature is not available for Windows 95, or later versions.)
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 logicalerror can often be the most insidious and difficult bug to detect. With logical errors, which arise from 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 > sign for comparing values, when it should have used a < 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 ASP 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 breakpoints, open your script with the Microsoft Script Debugger and set a 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.
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 ASP script contains a Stop statement that suspends execution before the script displays a result:
<%
dayvalue = 3
TheDay = WeekDayName(dayvalue)
Stop 'set breakpoint here.
Response.Write("Today is " + TheDay)
%>
When you request the previous script using your Web browser, the debugger starts and automatically displays the .asp file with the statement pointer indicating the location of the stop statement. Remember to remove Stop statements from production .asp files.
To add breakpoints to your server-side scripts written in Microsoft® 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 the Microsoft Script Debugger each time the script loops through a new value.
<%@ Language="JScript" %>
<%
for (var count = 1; count <= 10; count++) {
var eventest = count%2;
debugger //Sets breakpoint
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 the 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, mispelled commands or missing variables, certain types of logic and execution errors can arise from considerably less evident sources.