Error Trapping and Logging

[Previous] [Next]

If you program like me, your applications probably don't work correctly the first time you run them. To help us be more successful, Microsoft has created some error-trapping tools, logging features, and applications that work with the Exchange Event Service.

Microsoft Script Debugger

Your first line of defense against the bugs that always somehow find their way into programs is the Microsoft Script Debugger. We looked at the Script Debugger in the context of debugging Outlook scripts in Chapter 5. The same Script Debugger can be used to debug Exchange event scripts as well. To force your script to hit a breakpoint, use the Stop statement in VBScript and the Debugger statement in JavaScript.

Because the Script Debugger does not support remote debugging (at the time of this writing), you must run the debugger on the machine where the script is executing. For the Event Scripting Agent, this machine is the Exchange server where the script is currently executing. Figure 13-9 shows the Microsoft Script Debugger debugging a script.

Figure 13-9. The Microsoft Script Debugger allows you to step through your scripts running on the Exchange server.

Script.Response and Logging

The Script Debugger is an invaluable tool when developing your Event Scripting applications. However, once you deploy your solutions in your company, you probably do not want to run instances of the Script Debugger on your production servers. This is where your second line of defense comes in: you can call the Script.Response method in your scripts to write strings of text to the log files associated with your agents. Figure 13-10 shows an example of an agent log file.

Figure 13-10. An agent log file in Notepad. Each agent has an associated log file in which you can write your own status or error-logging information.

You can access the log file for your agent remotely in Outlook by accessing the Agents tab for the folder, selecting the agent, clicking the Edit button, and then clicking the Logs button. By default, your agents will log only errors that occur in your scripts, but you can extend their functionality by using the Script.Response method to help you debug problems or track the status of your scripts.

The Script.Response method takes a string argument, which allows you to write information into the agent logs. As mentioned earlier, these log files, by default, are 32 KB in size, and older events are written over as necessary when this size limit is exceeded. If you make multiple calls to the Script.Response method, the code will write only the most recent string passed to the method into the log. To avoid losing strings when making multiple calls to Script.Response, prefix the previous response string with a new response string. The Expense Report sample application shown later in this chapter demonstrates how to use this technique in your applications.

The Windows NT Event Log

One other line of defense that you have in debugging your applications is the Windows NT Event Log. When you set Logging Level in the registry to the maximum value (5) for the Event Scripting Agent, the Windows NT Event Log provides not only error information gleaned from your scripts but also general information about the status of the Event Service and what notifications it has received from the Exchange server. When you use the Script.Response method described earlier to track errors and status information for your scripts, the information will be added to the description field in the Event Detail dialog box for an Event Service entry in the Application Log, as shown in Figure 13-11. (To view these entries in Event Viewer, be sure to select Application from the Log menu.) This type of information can make it easier for you to track down bugs or failures in your released application.

Figure 13-11. The event details for the Expense Report application. Since the Script.Response method was used, the Description field has detailed information.