[This is preliminary documentation and subject to change]

# Debugging ASP Scripts

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 Tool

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:

- Run your server-side scripts one line at a time.
- Open a command window to monitor the value of variables, properties, or array elements, during the execution of your server-side scripts.
- Set pauses to suspend execution of your server-side scripts (using either the debugger or a script command) at a particular line of script.
- Trace procedures while running your server-side script.

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.

## Enabling Debugging

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:

- Manually open Script Debugger to debug your ASP server-side scripts.
- Use Internet Explorer to request an .asp file. If the file contains a bug or an intentional statement to halt execution, Script Debugger will automatically start, display your script, and indicate the source of the error.

## Scripting Errors

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.

### Syntax Errors

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

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.

### Logical Errors

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.

## Error Debugging Techniques

You can use several different debugging techniques to locate the source of bugs and to test your applications.

### Just-In-Time (JIT) Debugging

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.

### Breakpoint Debugging

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.

#### The Break at Next Statement

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.

### VBScript Stop Statement Debugging

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.

### JScript Debugger Statement Debugging

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.

## Tips for Debugging Scripts

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 Web site.

© 1997-2001 Microsoft Corporation. All rights reserved.