Scripts, iterators and exception handling (draft)

Original in Russian: http://programmingmindstream.blogspot.ru/2014/06/blog-post_4070.html

I quote:

"
Aspects of working with objects iterators

To check the functionality of the system while writing a test, one often needs to perform the iteration of all forms or special controls. The aim is to find a particular object or get a possibility to use one expression for all objects found (for example, writing the name and activity state of the object to a template).
A simple iteration based on using the WORDWORKER would be as follows:

 WORDWORKER “Forms iteration”
 WHILE ( … )
 ( …
 OBJECT VAR Form := ( … )
 Form ( WordToWork DO )
 )
 ;

In this example, forms searching is performed on general criteria. Each from is assigned to the variable Form. The expression would be used for every variable to set WordToWork DO. The same can be done using the procedure but WORDWORKER has a distinct advantage: the expression for every form would be set AT THE RIGHT. The code would be almost self-descriptive.
An example of using the word:

 “Forms iteration” ( Actions_for_any_found form )

Using this word we can easily write the tests functionality. For example, we can print out all controls on all forms:

 WORDWORKER “Controls iteration” OBJECT IN Form
 WHILE on_controls Form
 ( …
 ( WordToWork DO )
 )
 ;
 “Forms iteration” (
 “Controls iteration” )

In this case, we should remember that the form is set AT THE LEFT from the second WORDWORKER and the expression for controls printing is set AT THE RIGHT.
Suppose, we need to find a particular control through iteration and go out of the cycles (since there are two of them: forms iteration and controls iteration). A standard construct

 EXIT
 CONTINUE
 BREAK

is not appropriate here, since processing of standard exception is used in every WORDWORKER (as well as in any procedure):

 PROCEDURE “…”
 TRY
 …
 ( RAISE EXIT )
 …
 EXCEPT
 if Exception = EXIT then
 ( )
 else
 RAISE
 END
 ;

At the end of implementation the procedure the EXIT exception is created. When it gets to the block EXCEPT…END, it is processed (the exception is “dampened” or, in other words, popped from the stack). In other cases, if we get another exception (like AV or ASSERT), it is not processed at all and is pushed to the stack. Then, it moves to the top of the stack until it becomes the first (user would see a system error message) or until it gets to the block EXCEPT…END that describes further behavior at getting this exception.
When we try to use EXIT to exit from controls iteration, the current iteration with the current form ceases if the condition is fulfilled:

 “Forms iteration” (
 “Controls iteration” (
 If ( Condition ) than ( EXIT )
 )
 )

To stop the cycles correctly,  ASSERT can be used, though it is not always appropriate.
According to this logic, the exception should be created to stop objects iteration correctly and the exception should be processed in proper time, before it gets to the user.

 CONST cBreak ‘cBreak’
 : “Stop iteration”
 CBreak RAISE
 ;
 WORDWORKER “Perform iteration”
 TRY
 ( WordToWork DO )
 EXCEPT
 if ( CurrentException Exception:Message not  cBreak ) then
 ( RAISE )
 END
 ;

As a result, we get the code:

 “Perform iteration” (
 “Forms iteration” (
 “Controls iteration” (
 If ( Condition ) then ( “Stop the iteration” )
 )
 )
 )

The code would be multi-purpose. It would obviate the old code rewriting or partial duplication, if there is a possibility to check the other conditions similar in logic. The words “Perform iteration”, “Forms iteration” and “Controls iteration” will work either together or separately."