Debugging AppleScript in Mac OS 9 Script Editor

In Mac OS 9, Apple’s bundled Script Editor provided a lightweight environment for writing, compiling, and testing scripts. While it lacked modern integrated debugger capabilities such as line-by-line stepping and variable watchlists, it offered several core built-in features to help scripters diagnose issues. These built-in troubleshooting mechanisms included automated syntax checking, runtime error reporting with code highlighting, an Event Log window for tracking Apple Events, and a dedicated Result window.

Syntax Checking and Compilation Errors

The primary defense against script errors in Mac OS 9 was the Check Syntax button in the Script Editor toolbar. When clicked, Script Editor attempted to compile the plain text into AppleScript bytecode.

If the compiler encountered a syntax error (such as an unclosed block, invalid keyword, or misplaced punctuation), it:

  • Halted the compilation process immediately.
  • Displayed an alert dialog detailing the nature of the error (e.g., "Expected end of line but found...").
  • Automatically selected and highlighted the exact token or line in the script source where the parsing failure occurred.

Automatic Formatting

Upon successful compilation, Script Editor applied predefined styling rules set in the AppleScript Formatting preferences. Distinct fonts, sizes, and colors were automatically applied to language keywords, application keywords, variables, and comments. This automatic formatting served as an immediate visual check, allowing scripters to spot mistyped identifiers that failed to register as native keywords or application terms.

The Event Log

The most critical runtime debugging utility in Mac OS 9 was the Event Log (accessible via Controls > Open Event Log).

The Event Log tracked the execution of scripts in real time by logging:

  • Outgoing Apple Events dispatched to targeted applications.
  • Incoming replies, return values, and parameters returned by those applications.
  • Any custom messages generated using the log statement within the script (e.g., log "Current value: " & myVariable).

When a script failed during execution, reviewing the Event Log allowed developers to inspect the exact Apple Event that triggered the failure, the arguments passed to it, and any internal operating system error codes returned by the target application.

Runtime Error Reporting and Line Highlighting

When an unhandled exception or runtime failure occurred (such as referencing a non-existent file or dividing by zero), execution terminated immediately.

Script Editor responded by:

  1. Presenting an error dialog containing a plain-English explanation accompanied by the corresponding Mac OS error number (e.g., -1728 for "No such object" or -43 for "File not found").
  2. Moving the active text selection to the specific line of code that threw the exception, allowing the user to immediately identify the failing operation.

The Result Window

Under the Controls menu, scripters could enable the Result Window (Show Result). When open, this floating palette displayed the final value produced by the most recently executed command or handler. This provided a quick method to verify that a script statement produced the expected data type or output without needing to create explicit display alerts.

Troubleshooting Limitations in Mac OS 9

Mac OS 9's Script Editor did not include interactive debugging features such as pause/break execution, step-into/step-over navigation, or call-stack inspection. To troubleshoot complex logic paths, developers relied on inserting temporary display dialog or log commands throughout the script, or utilized third-party development utilities like Late Night Software's Script Debugger.