The error event is triggered whenever there is an error in the AFP page (i.e. not during the execution of an AFP method). You define the error event in the .code file by setting up the procedure Event_Error:
PROCEDURE Event_Error
IF Error.nError = 3 && File is in use
RETRY
ENDIF
EndProc
This method contains the object Error with detailed information about the current error. It provides various methods like a method for returning a complete HTML page with all error details. You will find more detailed information about the available properties in the reference section.
There are subtle differences in the code to be used under AFP and the code normally applied under Visual FoxPro. To direct the course of action you may use RETRY, RESUME, CANCEL or RETURN inside the procedure. However, this applies only to the code that is physically located inside the procedure. All sub-functions and methods have to opt for this alternative:
PROCEDURE Event_Error
DO CASE
CASE Error.nError == 3
HandleFileInUseError()
ENDCASE
EndProc
PROCEDURE HandleFileInUseError
Error.cAction = "RETRY"
EndProc
Instead of executing the command the property Error.cAction must be set for the desired action. Thereafter you may finish both the procedure and the error event with RETURN, as usual. This is the normal course of action. The use of commands customary under VFP was implemented as an additional feature to simplify the deployment of AFP.
Through RETRY you can re-run the line that caused the error. RESUME picks up at the subsequent line. CANCEL aborts the processing of the current document without deleting the existing output. If you want to display a separate error page you will have to use CANCEL. RETURN aborts the processing of the document and displays the standard error page. If you fail to set Error.cAction and you don't use any of the four commands in the error event this will always trigger the action RETURN, i.e. display the standard error message.
You can define the error event in two places – one of them being the file .afp.code where you define it specifically for each page, the other one being the file .afpa.code for application-wide error handling. The occurrence of errors in a page or of certain events of the application (provided these are triggered for every invocation) will result in the error event of the page being run first. Once this is concluded through RETURN, the error event of the application will be triggered. Only after it, too, initiates a RETURN action the standard error message will be returned. This means that you can easily handle general errors in the application without having to repeat them in the page.