...GET - Spinners | Hackers Guide to Visual FoxPro 7.0

AError()

This function, added in VFP 3, consolidated many of the separate functions found in FoxPro 2.x. Instead of remembering the names of a bunch of different functions that return bits and pieces of information when an error occurs (all those are still available, if you care to use them), you can use this function to put all the necessary information into a single array. Best of all, AERROR() can even be used to find out about errors that occur when Visual FoxPro talks to the rest of the world via OLE or ODBC.

Usage

nRows = AError( ErrorInfo )

The function returns the number of rows in ErrorInfo, usually one. ODBC errors sometimes return multiple rows because multiple errors occur.

The interpretation of the data varies depending whether it's a FoxPro, OLE or ODBC error. In each case, the first element is the error number and the next two spell out the error message. The charts in the online Help do a pretty good job of explaining each element, so we'll just mention a couple of things that aren't so clear.

Some FoxPro errors (like error 12, "Variable not found") also include the name of the item that caused the problem (with error 12, the variable name). In this case, the third element of the array contains the name of that item.

When an error is triggered because a field validation rule fires, the third column should get the name of the field. However, in VFP 5 and later, instead the third column contains the validation message (as does SYS(2018), the function this column is meant to replace). Starting in VFP 5.0a, the fifth column contains the field number, so there is some way to get at the information, but we sure wish they'd fix this one instead of telling us it's "by design."

For OLE, help says the first element always contains 1427 or 1429. We've been able to generate 1426 as an OLE error (actually one of the most common OLE error numbers), and the list of error messages implies that 1428 is also a valid OLE error.

ODBC errors behave differently than the others. The SQL functions generally return a value to indicate their success or failure. (A negative value represents failure.) But the failure doesn't fire the application's error handler—you have to handle the error yourself. Even though the error handler isn't called, AERROR() still can pick up the error information. In the example below, we check for the error and call our error handler explicitly.

We strongly recommend you use AERROR() rather than the functions it supersedes in your error handlers.

Example

ON ERROR DO Handler * Now force some errors. XYZ USE NoSuchTable oWord = CREATEOBJECT("Word.Application") oWord.Documents.Open("NoSuchFile") RELEASE oWord * Substitute the name of a data source that exists * on your system in the next line. nHandle = SQLCONNECT("Access With ODBC 2.0") IF SQLEXEC(nHandle, "SELECT * FROM NoSuchTable") < 1    DO Handler ENDIF = SQLDISCONNECT(nHandle) ON ERROR   PROCEDURE Handler * Handle errors that occur. * In this case, we'll just figure out which kind they are * and then save the information to a file.   LOCAL aErrData[1]   = AERROR(aErrData) DO CASE CASE aErrData[1,1] = 1526    * ODBC Error    WAIT WINDOW "ODBC Error Occurred" NOWAIT CASE BETWEEN(aErrData[1,1], 1426, 1429)    * OLE Error    WAIT WINDOW "OLE Error Occurred" NOWAIT OTHERWISE    * FoxPro error    WAIT WINDOW "FoxPro Error Occurred" NOWAIT ENDCASE   LIST MEMORY TO FILE ErrInfo.TXT ADDITIVE NOCONSOLE   RETURN