Error Conditions
See also Error Conditions Category.
The first section (below) provides general information about the use of Business Rules! error conditions. The second section describes each individual error condition and the types of errors it will trap.
Error conditions are keywords which are used to trap errors that occur during program execution. Each error condition keyword identifies one or more types of errors that typically occur during program execution.
General information
Application
Business Rules error conditions can be used in one or more of the following three situations: in the "error-cond line-ref" parameter at the end of most program statements, with the Exit statement and with the ON error statement. The following paragraphs briefly describe each of these situations.
End of Program Statement
When an error occurs during program processing, Business Rules first action is to check the end of the error-causing program statement for an "error-cond line-ref" parameter that addresses the specific error. If there are more than one of these parameters (perhaps including the Exit error condition described below), they are processed from left to right until an applicable error condition is found. If none is found, processing as specified by the ON error statement (described below) takes effect.
The "error-cond line-ref" parameter may be specified at the end of all the following statements: CLOSE, DELETE, LET, FOR, INPUT, INPUT FIELDS, LINPUT, ON GOSUB, ON GOTO, OPEN, PRINT, PRINT FIELDS, READ data, READ file-num, REREAD, RESTORE file pointer, REWRITE, RINPUT, RINPUT FIELDS, and WRITE.
Exit statement
When an error occurs and Business Rules discovers an Exit error condition at the end of the error-causing program statement, it examines the associated Exit statement (which is located at the line number specified with the error condition).
The Exit statement contains one or more "error-cond line-ref" parameters which are examined in left to right order. If Business Rules finds an error condition that addresses the error that occurred, it branches to the line number specified with that error condition. If it does not find an applicable error condition in the Exit statement, it continues looking for an applicable error condition in the original error-causing statement.
The Exit statement works in conjunction with the Exit error condition to provide "short-hand" error processing. The following error conditions may be specified as the "error-cond" portion of this parameter: CONV, DUPREC, EOF, ERROR, HELP, IOERR, LOCKED, OFLOW, NOKEY, NOREC, PAGEOFLOW, SOFLOW, or ZDIV.
ON error statement
When an error occurs on a statement where no "error-cond line-ref" parameter was coded, Business Rules! checks to see if the error is addressed in an ON error statement. This statement identifies the default error action for a particular error condition.
The error conditions which may be specified in the ON error statement are:
See also: On Error
Individual error conditions
ATTN
- Uses
The ATTN error condition may be used in the ON error statement, but it cannot be used at the end of a program statement or with the Exit statement.
- Error trap
ATTN traps the pressing of the F10 function key during program execution. It is generally used only for compatibility with IBM Business BASIC as it was used on the System/23.
CONV
- Uses
The CONV error condition may be specified at the end of a program statement, in the Exit statement and with the ON error statement.
- Error traps
- CONV traps the following four conversion errors
- 1.) A numeric input field contains non-numeric characters.
- 2.) The number is too big for the field.
- 3.) The I/O list item is numeric where the FORM format specification indicates a string, or visa-versa.
- 4.) A negative value is being input or output, but the PIC format specification does not specify a sign (negative symbol).
DupRec
The DUPREC, or duplicate record, error condition is used when a REC= clause is used on a file opened for the RELATIVE access method The DUPREC error condition may be used at the end of a program statement and in the Exit statement, but it is not accepted by the ON error statement.
Error Traps:
DUPREC traps an attempt to WRITE to an existing record (REWRITE must be used instead of WRITE).
EOF
- Uses
The EOF error condition may be specified at the end of a program statement and in the Exit statement, but it is not accepted by the ON error statement.
- Error trap
EOF traps three error situations: when there are no more records in the file during input (for a READ file, INPUT, or LINPUT statement), when there is not enough file space during file output (for a PRINT or WRITE statement) or when there is not enough data in DATA statements (for a READ data statement).
ERROR
The ERROR error condition may be used at the end of a program statement, in the Exit statement and in the ON error statement.
- Error traps
ERROR traps all errors, including all the errors that are trapped by other error conditions (except PAGEOFLOW). Since ERROR will trap any error, it must be placed at the end of a list of error conditions when more than one is specified for the same statement. Any error conditions which follow it will be ignored.
EXIT
- Uses
The Exit error condition may be coded at the end of program statements that accept error conditions. It cannot be used with either the ON error or Exit statements.
- Error traps
Exit does not actually trap errors. Instead, it points to a separate Exit statement that contains a list of error conditions that may address the error that occurred.
When an error occurs and Business Rules discovers the Exit error condition at the end of the error-causing program statement, it immediately examines the associated Exit statement (which is located at the line number specified with the error condition). If it finds an error condition that addresses the error that occurred, it branches to the line number specified with that error condition. If it does not find an applicable error condition in the Exit statement, it continues looking for an applicable error condition in the original error-causing statement.
Business Rules always examines the contents of the Exit statement when it encounters the Exit error condition, it is best (and fastest) to place the Exit error condition after any other error conditions that are listed at the end of a program statement. The Exit statement usually includes general error processing that can be used several places in the program. Error processing specific to a particular statement should be coded before the Exit error condition so that the specific items will be processed before the more general ones.
FKEY num-expr
The FKEY error condition is available for use only with the On error statement. It cannot be used at the end of a program line or in the Exit statement.
Parameter:
The "num-expr" portion of the FKEY error condition is a numeric expression that evaluates to a number from 1 to 49. The value of the num-expr determines which function key, when pressed, will activate the ON statement's GOTO.
Error traps:
During program processing (the status line says "RUN"), FKEY traps the pressing of a function key which is specified by the "num-expr" parameter. Business Rules tests for the pressing of function keys before execution of each line number. Multiple uses of the ON FKEY statement do not impact program performance.
FKEY has no effect during other operation modes such as INPUT or SELECT (see the CMDKEY function for information about trapping function key selections during these modes). If FKEY is set to SYSTEM, the value of ERR will be set to 1. If FKEY is not set and the operator presses a function key during processing, it will be ignored.
When FKEY is set to either SYSTEM or GOTO and the specified function key is pressed, the keyboard buffer will be cleared up to the pressing of that key in the same manner that pressing Ctrl+A clears the buffer.
HELP
- Uses
The HELP error condition may be specified at the end of a program statement, in the Exit statement, and with the ON error statement.
- Error traps
When HELP is coded at the end of a statement, it traps the pressing of the <HELP> key. This end-of-statement use of HELP takes effect only when the operator presses <HELP> during execution of a keyboard input statement (INPUT, RINPUT, LINPUT, INPUT FIELDS and RINPUT FIELDS) and when the HELP error condition is coded at the end of the input statement.
The use of HELP with the ON error statement is somewhat different from the use of other error conditions. When ON HELP SYSTEM is in effect and the <HELP> key is pressed (and not otherwise trapped by an end-of-line HELP condition), Business Rules executes an implied HELP$ call. This HELP$ call accesses the keyword and file name which are named by the BRConfig.sys file's HELPDFLT specification. If HELPDFLT has not been specified, ON HELP SYSTEM operates as ON HELP IGNORE. For additional information, see the ON error statement and the Help Facility chapter.
LOCKED
- Uses
The LOCKED error condition can be used at the end of a program statement, in the Exit statement, and in the ON error statement.
- Error traps
- LOCKED traps two types of errors
- 1.) the record is locked at another workstation (error code 0061)
- 2.) file- sharing rules are violated (error code 4148)
LOCKED should be listed before the IOERR or ERROR error conditions when it appears in a list of error conditions, as IOERR and ERROR will trap all the errors that LOCKED traps plus many more. When error processing is handled at the ON error statement level, however, Business Rules automatically invokes the error action which is most specific to the error which has occurred.
NOKEY
- Uses
The NOKEY error condition can be used at the end of a program statement and in the Exit statement, but it cannot be specified in an ON error statement.
- Error traps
NOKEY traps the error that occurs when a file does not contain the specified key when a KEY= or SEARCH= clause is used on a file opened for the KEYED method of access.
NOREC
- Uses
The NOREC error condition can be specified at the end of a program statement and in the Exit statement, but it cannot be used with the ON error statement.
- Error traps
- NOREC traps the following three types of errors when a file is opened for RELATIVE access with a REC= clause
- 1.) The specified record has been deleted.
- 2.) The number is at least two greater than the last record number of the file (for WRITE).
- 3.) The number is greater than the last record number in the file (for READ).
PAGEOFLOW
- Uses
The PAGEOFLOW error condition can be specified at the end of a program statement, in the Exit statement and with the ON error statement.
- Error traps
PAGEOFLOW traps the error that occurs when the number of lines printed since the last page feed equals or exceeds the page length specified in an OPEN display statement. (The default page length is 60 lines.)
PAGEOFLOW is unique in that it is the only error condition that will trap the page overflow condition. If PAGEOFLOW or ON PAGEOFLOW is not used, the page overflow will be ignored. Neither ERROR nor IOERR will trap this condition.
OFLOW
- Uses
The OFLOW error condition can be specified at the end of a program statement, with the Exit statement or in the ON error statement.
- Error traps
The OFLOW error condition is a System/23 compatibility feature. On the System/23, it trapped errors that occurred when the system computed a number having an absolute value greater than the largest numeric value of the system. This feature is hardware dependent and has no relevance to DOS, Unix or Linux systems.
IOErr
The IOErr error condition may be specified at the end of a program statement, in the Exit statement, and with the ON error statement.
IOErr does not trap error 4152.
Error Traps:
IOERR traps all errors that occur in I/O statements, including some errors, which are more specifically trapped by other error conditions. One exception to this rule is that IOERR does not trap PAGEOFLOW errors.
In a list of error conditions, IOErr should be placed after LOCKED, as IOERR traps the same errors that LOCKED trap, plus others. Similarly, IOErr should be listed before ERROR in a program statement, as ERROR will trap all the errors that IOErr traps. When error processing is handled at the ON Error statement level, however, Business Rules automatically invokes the error action which is most specific to the error which has occurred.
SOFLOW
- Uses
The SOFLOW error condition can be specified at the end of a program statement, in an Exit statement, and in the ON error statement.
- Error traps
- SOFLOW traps the following three errors
- 1.) The number of input data characters is greater than the defined length of the string variable used for assignment in READ, REREAD, INPUT, or LINPUT statements.
- 2.) The length of the string expression in the I/O list is greater than the field width defined in the FORM statement's format specification.
- 3.) The length of an assigned-from string (B$ in A$=B$) is greater than the dimensioned length of the assigned-to string (A$).
ZDIV
- Uses
The ZDIV error condition can be used at the end of a program statement, in the Exit statement, and with the ON error statement.
- Error trap
ZDIV traps the error that occurs when division by zero is attempted.