Specifies procedure behavior when a fatal procedure error occurs. A fatal procedure error is not a GPF or other Windows error. Rather, it is an error that Arbutus Analyzer or ConnectPlus cannot recover from, such as attempting to open a table that doesn’t exist.
Set Fatal enables:
| • | called procedure to halt and return to the calling procedure, or |
| • | procedure to continue on to the next command, or |
| • | termination of all active procedures with control returned to the user, or |
| • | execution of a named procedure or procedure label should the active procedure have a fatal error |
In all cases, use of Set Fatal suppresses any popup-messages upon error so that a procedure isn't stalled waiting for the user to click [OK], or so that a scheduled procedure does not quit because of a pop-up message.
SET FATAL {n|RETURN|NEXT|TO Procedure_Name}
SET FATAL n only applies when an external program calls Analyzer or ConnectPlus and will return an error code to the external calling program (n must a whole number from 1 to 250 inclusive).
SET FATAL 0 will disable n or RETURN, setting the default fatal error behavior to close all procedures and return control to the user.
SET FATAL RETURN will enable a called procedure to return control and execution to the calling procedure upon a fatal error. This is most useful when a number of independent procedures are being called by a main procedure sequentially as it enables the remaining procedures to execute.
SET FATAL NEXT will advance to the next command rather than return to the calling procedure.
SET FATAL TO Procedure_Name may be set instead of or in conjunction with the other Set Fatal modes (cancel procedures, return to calling procedure or exit). It causes the named procedure or procedure label to be executed if a fatal error occurs. This is most useful if clean-up operations need to be performed for the executing procedure. The following behavior occurs depending on which (in any) Set Fatal parameter is used in conjunction:
| • | if used alone, the named procedure or procedure label is run and then all procedure execution stops (see syntax options below) |
| • | if used in conjunction with Set Fatal n, the named procedure is run and then the application exits |
| • | if used in conjunction with Set Fatal RETURN, the named procedure or procedure label is run and then execution is returned to the calling procedure. |
| • | if used in conjunction with Set Fatal NEXT, the named procedure or procedure label is run and then execution is returned to the next command |
Note: Issuing “Set Fatal To” with no named procedure will disable the clean-up procedure.
When used and a fatal error occurs, the “SET FATAL TO procedure_name” call is cleared so that errors in the clean-up logic don’t call an infinite loop. If you want your clean-up procedure to be persistent, make the last line in the clean-up procedure “SET FATAL TO procedure_name” to re-instate the error trapping.
SET FATAL TO procedure_name
SET FATAL TO ".procedure_label"
SET FATAL TO "procedure_name.procedure_label"
Note: When referencing a procedure label in the Set Fatal command, you must surround the reference with quotes as shown in the last two examples above.
When the SET FATAL command is triggered, a system variable is automatically created called Command_Error.
You can test for the existence and value of this system variable using an IF command, and if the variable exists possibly send an e-mail message using the Notify command to alert someone of the problem:
IF ISDEFINED("Command_Error") NOTIFY SENDER ...