Understanding Synergy DBL errors

Synergy DBL uses the following types of error messages:

Trapping runtime errors

Trappable runtime errors are those from which your program can recover. You can trap these errors using the ONERROR statement, end-of-file labels in some of the I/O statements, and I/O error lists that can be associated with any I/O statement.

When establishing error traps, your program indicates errors that are to be trapped, as well as the label(s) to which execution control is to be transferred. When your program traps an error, program control transfers to the appropriate error handling code as if a GOTO statement had occurred. For more details, see ONERROR and Error trapping.

Every trappable error has an error literal or a mnemonic that begins with $ERR_. For example, the error literal for ARGSIZ is $ERR_ARGSIZ, and the error literal for ILLCHN is $ERR_ILLCHN. You can use these error literals with ONERROR statements, in I/O error lists, and wherever you can use a literal. For example:

onerror ($ERR_IOFAIL, $ERR_DIGIT) proc_err1, ($ERR_EOF) proc_err2
read(1, data, rec_id) [$ERR_IOFAIL=proc_err1]

Understanding nonfatal compiler errors

Nonfatal compiler errors can be reported as errors (E-) or warnings (W-). For example, ABSIMP can be invoked as %DBL-E-ABSIMP or %DBL-W-ABSIMP. A compiler error that’s reported as a warning by the dbl compiler with the -qnet option will be reported as an error in the Synergy .NET compiler.

Although a nonfatal error doesn’t abort compilation, no output file will be created if an error is reported. You must fix the error before you can proceed.

If a warning is encountered, the compiler still creates an output file. However, we recommend that you investigate the cause and fix the problem. On OpenVMS, compiler warnings cause runtime warnings, so all warnings must be fixed on OpenVMS.

Note that the -W compiler option (/WARNINGS on OpenVMS) enables you to control which warning levels will be displayed. (See Warnings in the “Compiler Options” table for details.) You can disable individual warnings with the -WD option. Warnings can also be forced to errors with the -qerrwarn option.

Understanding fatal errors

Fatal, nontrappable errors are indicated with F-; they will be reported as %DBR-F-mnemonic for runtime errors and %DBL-F-mnemonic for compiler errors. (On OpenVMS, both runtime and compiler errors are reported with %DBL.)

Fatal errors result in immediate, unconditional termination of program execution. When a program is abnormally terminated because of a nontrappable error (or a trappable error for which no error trapping was established), an error message and a traceback of the program are generated. The traceback is a record of how your program reached the line of code that encountered the error.

The traceback appears beginning at the line at which the error was detected, and proceeds backward until all CALLs and XCALLs have been displayed. The following is an example of traceback:

%DBR-F-CHNUSE, Channel is in use
%DBR-I-ATLINE, at line 584 in routine M_PROCESS_P
     Called from line 814
     Called from line 462
%DBR-I-ATLINE, at line 335 in routine M_PROCESS
%DBR-I-ATLINE, at line 156 in routine TXTUTL

If you’re running your program in the debugger and a fatal error is encountered, the debugger generates the fatal error message with its traceback and break at the line that caused the fatal error. This feature enables you to remain in the debugger for post-error debugging.

Using error literals instead of numbers

In addition to a literal, each error message also has an associated number. We strongly recommend that you use error literals instead of error numbers to make your code easier to read and maintain.

Customizing error messages

Error numbers and messages are defined in the syntxt.ism message library. You can use the Synergy UI Toolkit Control Panel (synctl) to translate or otherwise customize these messages if you’d like.

Synergy .NET applications do not use syntxt.ism and so do not support customized messages.