On a large remote network is can be very difficult to diagnose problems from a distance. Getting users to relay to the developer the full information about an error can be very difficult. To overcome this problem it is helpful to install an Error Handler at Startup and keep it in effect for the duration of the running of the database. But just having this method in place is only the first step in getting the information back to the developer.

The first step is to get as much information about the error as possible. To get as much information as possible, the error handler should include a way to capture all the error information possible. Beginning in 4D v12 and in v13, when an error occurrs and the error handler is called there are three process variables populated and explaned below.

ON ERR CALL ( "errorMethod" ) 

These variables can only be used in an error-catching method installed by the ON ERR CALL command. If you want for them to be accessible in the method that caused the error, copy their value into your own process variables.

• Error: Longint type system variable. This variable contains the error code. 4D error codes and system error codes are listed in sections of the Error Codes theme.
• Error method: Text type system variable. This variable contains the full name of the method that triggered the error.
• Error line: Longint type system variable. This variable contains the line number at the origin of the error in the method that triggered the error.

Great as these three variables are they are not the complete picture. It will also be helpful in this method to get the error stack, as documented below:

GET LAST ERROR STACK ( codesArray ; intCompArray ; textArray ) 

The information is returned in three synchronized arrays:

• codesArray: This array receives the list of error codes generated.
• intCompArray: This array contains the codes of the internal components associated with each error.
• textArray: This array contains the text of each error.

To complete the picture, environmental information should also be gathered, using commands such as Current date, Current time, Current user, Current machine, and PLATEFORM PROPERTIES.

This information now needs to be preserved and delivered to the developer in a timely manner so that it can be acted on as soon as possible.

To preserve the information it can be save to a private table, exported to a log, or exported ot separate files.

To get this information back to the developer 4D can be used to post the information to the developer. It can be posted using 4D commands to FTP, SOAP, or email this information to the developer.

The developer is now enabled to respond quickly with the most complete information available about and error and empowered keep the customer happy with his timely and excellent support.