Error Event

You could write a book about error handling in Visual FoxPro. In fact, we wish someone would. There are multiple ways to tackle the issues involved. The Error Event is one part of the picture—it fires when an error occurs in any method of an object.

Usage

PROCEDURE oObject.Error
LPARAMETERS [ nIndex, ] nError, cMethod, nLine

The Error Event lets you handle errors locally, but should you? Doug has proposed the most elegant error-handling scheme the rest of us have seen. (He insists that we point out that his scheme is based on ideas he heard from Mac Rubel and Lisa Slater Nicholls.) Each object handles what it can and passes what it can’t up the class hierarchy. If nothing in that hierarchy can deal with the error, it goes up the containership hierarchy (traveling up the class hierarchy of each container along the way). Finally, if you reach the ultimate parent of all parents and still haven’t dealt with the error, a global error handler kicks in. (You can download an article describing this idea in detail from the Technical Papers section of Doug’s Web site, doughennig.com.)

So when does Error fire, anyway? It fires when something in a method of the object causes an error. If you mess up the call to an object’s method, though, it’s not the called object whose error handler fires, it’s the calling object. For example, if a method of cmdDoIt calls the AddItem method of lstMyList, but messes up the call as lstMyList.AddItm, cmdDoIt’s Error Event fires because it can’t find the called method.

If there’s no code at all in the Error method (and nothing in the Error methods all the way up the object’s class hierarchy), an object’s errors get passed on to the current error handler set up with ON ERROR. That’s good.

The bad news is what happens if an error occurs in the Error method. Does it call your ON ERROR handler? Nope, you get the usual FoxPro Cancel/Suspend/Ignore dialog. Better debug those Error methods really well before you send them out to users.

Error 1116, "Too many windows are open," does not invoke the Error method, nor does it fire the ON ERROR handler. We sort of understand why. This error is a resource issue, but there's no guarantee that our error handlers will need any more windows, so why not give us a shot at it?

You can accidentally mess yourself up as well. If all the code in the Error method is commented out, you get no indication of the error. Your ON ERROR handler isn’t called in this case because Error contains code, even if it is commented out. This isn’t a bug, but it is confusing.

Don’t call the ERROR command in your Error method, either. This is the same as having a real bug in your Error code and calls the C/S/I dialog.

In VFP 6 and later, it appears that every base class has an Error method. In VFP 5, Separator does not, and in VFP 3, neither do Column and Header. In those versions, an error in the code of these objects always invokes the global ON ERROR handler—not, as you might suspect, the error handler for the container objects.

Example

* For an OLE control, we might trap OLE errors locally.
PROCEDURE oleMyGeneral.Error

LPARAMETERS nError, cMethod, nLine

IF nError = 1427 or nError = 1429   && OLE errors
   LOCAL ARRAY aErrInfo[1]
   = AERROR(aErrInfo)
   * Now figure out how to handle this OLE error.
ELSE
   * Call the application's error handler.
   oApp.HandleError(This.Name,nError,cMethod,nLine)
ENDIF

RETURN

See Also

AError(), Error, Error(), On Error