A simple error handler that is adequate for most interviews is as follows. All scripts created using the Build activity have this code inserted automatically at the start of the routing section.

The variable names in the example all start with two underscores but this is not a requirement. The reason is that this is code is automatically generated in the Build activity, so there needs to be some way of ensuring that the variable names do not clash with any that the scriptwriter might use for question names in the script. If you write your own error handler you can use any names you like as long as they do not clash with variable names in the rest of the script.

The first two lines of code are not part of the error handler. They prevent the error handler being enabled if the script is being run in UNICOM Intelligence Professional, so that any script errors will cause the interview to fail and display their messages on the screen. The key part of this section is:

which directs all errors to the error handler. If you write an error handler, you should include a statement like this at or near the top of the routing section.

The error handler is defined under the DefaultErrHandler label. When an error occurs, the error handler writes the error message and the line number at which it occurred, to the log file (IVW*.tmp). The line number is the line at which the error affected the interview, which might or might not be the line number that contains the invalid instruction. Sometimes, an error in one statement does not have an effect until a little later in the script. However, the line numbers are usually a reasonable guide to where to start looking.

The MaxTestErrors property specifies the maximum number of errors that will be displayed in a test survey before the survey terminates. The default value is 9.

If the interview is a test interview, the message is also displayed as a banner at the top of the current page. After an error, the Resume Next line instructs the interview to continue.