From BR Wiki
Jump to navigation Jump to search

The Retry (RETR) statement transfers control to the clause that caused the most recent error.

As a parameter of the Open Communications statement, and for formats with error detecting protocols, the "RETRY" parameter specifies how many times to attempt to send or receive the record before generating an I/O error. The default is RETRY=5.

Comments and Examples

Business Rules! provides two statements for transferring control at the end of an error processing routine. Their function is analogous to the Return statement at the end of a subroutine. RETRY transfers control to the statement which caused the most recent error; Continue transfers control to the next statement after the one which caused the most recent error.

Any error condition that can cause an error transfer sets the statement to be executed by RETRY.

In the example below, the error in line 110 will transfer control to line 900. The RETRY statement in line 920 will transfer control back to line 110 which will succeed after the value of Z is changed from 0 to 1. NOTE that the corrective action in this example may not be a good general solution for all errors trapped by ZDiv:

00120 STOP
00900 FIXZDIV: Z=1
00910 PRINT "Division by zero, line"; LINE
00920 RETRY



Technical Considerations

1.) If no error has occurred (or if the only error was suppressed by an ON IGNORE statement), RETRY generates an error message.
2.) If a second error occurs before RETRY is executed, the first return address is lost. (An exception to this is when the NOKEY error condition is used and a 4273 (help topic not found) error occurs.) It is the responsibility of the programmer to avoid the occurrence of subsequent errors. For this reason, and to avoid a continuous loop, some programmers use ON ERROR SYSTEM or ON error-cond SYSTEM at the start of their error handling routines. Immediately before the RETRY statement, they end by calling a subroutine to reinstate the original error processing conditions.
3.) When the 4273 (help topic not found) error is trapped by a NOKEY condition, ERR and LINE are not set. Such an error would typically occur on an attempt to use the HELP$ function in an error trapping routine. RETRY and CONTINUE will continue to remain effective for the original error.
4.) If the statement to be retried is INPUT FIELDS or RINPUT FIELDS, the cursor will automatically be positioned on the field which caused the error. This feature is very useful after processing a HELP error condition on an INPUT FIELDS or RINPUT FIELDS statement (see Help Facility for examples).
5.) When a program is interrupted, typing RETRY is the same as typing GO.
6.) For additional information on error processing, see the ON error, EXIT, and CONTINUE statements. Also see Error Conditions.