Retrying a failed operation (error handling)

[Pat France]

There are two kinds of functions with respect to retrying a failed operation: those that inherently support a retry and those that don't.

Whether an automatic retry is possible for a given function is stored in the :canRetry member variable of the error object created when the function fails; a value of true (.T.) means the function supports automatic retries.

Automatic retries​

Functions that support retries allow implementing suitable error handling strategies in the application's error handler. This way, an application can establish a default behavior of always retrying certain operations a certain number of times before notifying the user. This kind of handling can also be implemented in a local error handler installed using ErrorBlock().

Functions supporting automatic retries automatically increment the :tries member of the error object upon each retry. All info required for initiating a retry is automatically retained by the function from the original call.

Application-defined retries​

Errors in functions that do not support an automatic retry must be dealt with directly in the code using the function instead. Typically, this is done by using BEGIN/END SEQUENCE and by handling the error in an associated RECOVER block. The same is true in scenarios consisting of several operations that each could fail, but which should not be reported as individual errors to the user. Example: loading a set of configuration files.

This form of implementing retries for failed operations tends to be more complex. For example, a loop must be implemented for the desired number of retries and status info must be maintained for keeping track of things.

Examples for both of these error handling strategies are given in the documentation of the Error class: https://doc.alaska-software.com/content/cls_xppcref_error.html