As we already said at the beginning of this section, AFP error handling is exception-based. Whenever an error occurs the current procedure is abandoned in its entirety. This is to ensure that the process will not continue with false or erroneous intermediate results and that no potentially risky operations like the deletion of a record will be executed. Theoretically, functions can be aborted at any desired point in time. Often, though, you will find the following code at the start of a procedure:

LOCAL lcDeleted

lcDeleted = SET("Deleted")

SET DELETED OFF

And at the end of a procedure, for clearing up:

SET DELETED &lcDeleted

Similar constructions are employed for the majority of the SET commands and for settings in the current work area. If an error occurs in the course of the procedure, these modifications will not be accurately undone. App.Finally() is well suited to handle this problem. This method provides one or more commands, separated by CHR(13)+CHR(10), as a parameter. It returns an object reference. When you use this method, the code will be as follows:

LOCAL loDeleted

loDeleted = App.Finally( "SET DELETED "+SET("DELETED") )

SET DELETED OFF

There is no need for code at the end of the procedure, as the method Finally takes advantage of a Visual FoxPro trick. It returns the object that executes the delivered code in the event Destroy. This will be triggered whenever either you or FoxPro release the object. The latter happens automatically at the end of the procedure. Aside from App.Finally() there is also Document.Finally(). The difference between these two is in the session ID. Only Document.Finally() is available if you are not using an application.