Retry - Revision history

Laura: /* Syntax */

2014-04-29T14:22:10Z

Syntax

← Older revision		Revision as of 14:22, 29 April 2014
Line 18:		Line 18:

	===Syntax===		===Syntax===
			RETRY
	[[Image:Retry.png]]		[[Image:Retry.png]]

Laura at 15:40, 6 August 2013

2013-08-06T15:40:13Z

← Older revision		Revision as of 15:40, 6 August 2013
Line 1:		Line 1:
	The '''Retry''' (RETR) [[statement]] transfers control to the clause that caused the most recent error.		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===		===Comments and Examples===

Laura at 01:45, 6 February 2013

2013-02-06T01:45:28Z

← Older revision		Revision as of 01:45, 6 February 2013
Line 1:		Line 1:
	The '''Retry''' (RETR) [[~~command~~]] transfers control to the clause that caused the most recent error.		The '''Retry''' (RETR) [[statement]] transfers control to the clause that caused the most recent error.

	===Comments and Examples===		===Comments and Examples===
	[[Business Rules!]] provides two ~~commands~~ 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.		[[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.		Any error condition that can cause an error transfer sets the statement to be executed by RETRY.
Line 28:		Line 28:

	<noinclude>		<noinclude>
	~~[[Category:Commands]]~~
	[[Category:Statements]]		[[Category:Statements]]
	[[Category:Branching Statements]]		[[Category:Branching Statements]]
	[[Category:Error Handling Statements]]		[[Category:Error Handling Statements]]
	</noinclude>		</noinclude>

Laura: /* Technical Considerations */

2013-02-06T01:39:54Z

Technical Considerations

← Older revision		Revision as of 01:39, 6 February 2013
Line 29:		Line 29:
	<noinclude>		<noinclude>
	[[Category:Commands]]		[[Category:Commands]]
			[[Category:Statements]]
	[[Category:Branching Statements]]		[[Category:Branching Statements]]
			[[Category:Error Handling Statements]]
	</noinclude>		</noinclude>

Laura: /* Technical Considerations */

2013-02-03T21:20:10Z

Technical Considerations

← Older revision		Revision as of 21:20, 3 February 2013
Line 24:		Line 24:
	: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).		: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]].		: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]].		:6.) For additional information on error processing, see the [[On Error\|ON error]], [[EXIT]], and [[CONTINUE]] statements. Also see [[Error Conditions]].

Laura: Created page with "The '''Retry''' (RETR) command transfers control to the clause that caused the most recent error. ===Comments and Examples=== Business Rules! provides two commands fo..."

2013-02-03T21:19:08Z

Created page with "The '''Retry''' (RETR) command transfers control to the clause that caused the most recent error. ===Comments and Examples=== Business Rules! provides two commands fo..."

New page

The '''Retry''' (RETR) [[command]] transfers control to the clause that caused the most recent error.

===Comments and Examples===
[[Business Rules!]] provides two commands 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]]:

00110 LET X=5/Z ZDIV FIXZDIV
00120 STOP
...
00900 FIXZDIV: Z=1
00910 PRINT "Division by zero, line"; LINE
00920 RETRY

===Syntax===
[[Image:Retry.png]]

===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]].

<noinclude>
[[Category:Commands]]
[[Category:Branching Statements]]
</noinclude>