Understanding ASP Script Processing
Understanding how client scripts are processed and how errors are handled can help you debug client scripts successfully.
Processing Client Script
Microsoft Internet Explorer processes the client script. The browser calls the appropriate run-time module to process VBScript scripts or JScript scripts.
Client scripts are initially parsed when the Web document is loaded into the browser. During this parsing phase, the browser reports any syntax errors that it finds.
After parsing a section of script, the browser executes it. Global or inline scripts, which are scripts that are not part of an event-handling subroutine or function, are executed immediately. Event-handling subroutines or functions, and procedures that are called by other procedures, are parsed immediately but are not executed until triggered by an event or called by another procedure.
If a run-time error occurs when a client script is executed, an error message is displayed and the script containing the error stops. Other client scripts in the document can still run (unless you start the debugger). If the script containing the error is called again, the error message is displayed again.
Depending on the language you are using, you might be able to include statements in your scripts to trap run-time errors and run your own error procedures. For example, in VBScript, you can use the ON ERROR statement to establish error trapping. For more details, see the documentation for your scripting language.
Processing Server Script
Most server script is not event driven. Instead, when an ASP file is requested, the server reads the page and processes all server script from top to bottom. Inline script embedded in HTML text is passed back to the client for handling.
Not all server script is executed immediately. As with client script, server script can include functions and subroutines that are executed only when they are called from other procedures.
Global.asa files are a special case. The Application_OnStart and Session_OnStart procedures in these files are executed only once for an application and for a session. Therefore, to debug these events easily, you must embed debugging statements in the file. For more information, see Debugging a Global.asa File.