Try – Recover – Escape

 

Why do I get a WHERR 8007 when I use an ESCAPE statement?

If an ESCAPE statement is not caught by a RECOVER section, the script will terminate after printing the line number on which the ESCAPE was invoked, along with a WHERR 8007. The WHERR is informational, since an ESCAPE implies that an unexpected condition was encountered in the script. If you wrap the script’s procedural code in a TRY/RECOVER block where the RECOVER section is empty, the WHERR 8007 will be masked since the ESCAPE will be caught.

Tip: an ESCAPE statement should not be used for standard program control flow, but to handle exceptional situations and events.

 

How can I exit prematurely from a script?

An ESCAPE statement outside of a TRY/RECOVER block causes Warehouse to stop processing the script at run-time. On the other hand, an EXIT statement immediately exits WAREHOUSE during the compilation phase. So if your intention is to exit prematurely during run-time, use the ESCAPE statement.

An ESCAPE statement placed within the TRY section of a TRY/RECOVER block will be caught by that block’s  RECOVER statement. The Warehouse code in the RECOVER may then decide either to handle the error condition and continue processing or else to pass control upward by means of another ESCAPE statement.

If the Warehouse code decides to issue a second ESCAPE from within the RECOVER section and this second ESCAPE  is nested within another enclosing TRY/RECOVER block, then the higher-level RECOVER section will catch this ESCAPE. Otherwise,  if  the second ESCAPE is not enclosed by another TRY/RECOVER block, Warehouse will display both the escape message and an error message and stop processing the script.

The following example illustrates the behavior of ESCAPE statements within nested TRY/RECOVER blocks, and shows how the escape message text is accessible in the $ERR.ESCMSG Warehouse variable. The script begins logical execution on line 4, with the second RECOVER beginning at line 11. Line 12 is the location of the final ESCAPE.

1> try
2>
3>     try
4>         escape “escape 1”
5>     recover
6>        print “in 1st recover:”, $err.escmsg
7>        escape “escape 2”
8>     endtry
9>
10> recover
11>    print “in 2nd recover:”, $err.escmsg
12>    escape “escape 3”
13> endtry

in 1st recover: escape 1
in 2nd recover: escape 2
escape 3
Error in statement 12 (WHERR 8007)

 

Why won’t my script branch to RECOVER on a COPY error? 

try
copy emp-rec to sol24.emp; errors to sol24_errors;wait
recover
setvar error_count = error_count + 1
print “new error:”, error_count
endtry

The ERRORS TO directive takes precedence over the RECOVER. You should choose one error-handling option or the other.