Wiki Home

Error Handler


Namespace: Wiki
Proposed definitions:

Event: an action triggered by something the user or the system does.
EventHandler: the code that gets executed when the corresponding event occurs.

Let's examine this in the context of Errors:

Error Event: The occurrence of an error.
Error Handler: The routine that gets executed when an Error Event occurs.

In this context, "routine" covers all of the code that is specific to handling the event.
  1. It can be a simple command. on error quit.
    In this case, quit is the error handler.

  2. Error handlers can make use of other services. The other services are called by the error handler, but are not part of the error handler. on error messagebox( "Error!" )
    The messagebox function is not the error handler, just the call and its parameter.

  3. Error handlers can have subroutines that are part of the whole error handler.
    on error do gErrHlr
    procedure gErrHlr
    messagebox( "error" )
    return
    

    The call to gErrHlr and the gErrHlr procedure are the error handler.

  4. Error handlers can be built into classes, which take precedence over the on error setting.
    Define class cFoo as Custom
    Function error( tnErr, tcMth, tnLin )
    Messagebox( "Error!" )
    Return
    Enddefine
    

    In this case, cFoo::error is the error handler, which will respond to any Error Event caused by the cFoo class or its descendants.

  5. VFP provides some functions that are used by error handlers. on error ? message()
    Is the message function an error handler? Tough call. Ill defer this one to someone else. Following the above logic, the answer is a definitive NO and Yes :-). I believe it's an error handler from VFP's perspective and a called service from the perspective of the error handler in your program.Darrell Greenhouse

  6. The default VFP error handler displays a dialog box displaying the error message and gives the user the options of {Cancel, Suspend, Ignore, Help} or {OK, Help} depending on whether the error occurred in a program or interactively. In this case, the error handler is the code contained in VFP.

  7. In the following code, an error in the SQLexec function is indicated by a return code less than 0. The code in the IF block executes when there is an error, so it is the error handler.
    lnResult1 = SQLexec( lnCon, lcSqlCmd  )
    if lnResult1 < 0
    	CRLF = CHR(13) + CHR(10)
    	aerror( laErr ) && Data from most recent error
    	lcErrMsg = lcSqlCmd + CRLF
    	for each lxErr in laErr
    		lcErrMsg = lcErrMsg + CRLF + transform( lxErr, "" )
    	endfor
    	messagebox( lcErrMsg )
    	_cliptext = lcErrMst && now you can paste it
    endif
    



-- Carl Karsten
1. A module or object that intercepts errors.
(Alternately:) 2. What is specified by ON ERROR

Does anyone have any examples or sample code?
There is a nifty little error class in the FoxFoundationClasses-- Steven Black
Things that error handlers can do:
  • Log useful information so that a developer can examine it later. The user cannot be relied on for anything.
  • Give the user some choices; some problems (like disk space) are within the user's ability to rectify.
  • Behave differently if a "Developer mode" flag is set. We developers like lots of information right away; users generally get one button that closes the application.
  • Be interactive or non-interactive (someone give me an antonym of interactive.. batch mode, silent, automatic). An interactive error handler has a UI and expects a user to participate in the handling (could be as little as "read the error message and hit ok"). The alternative is to have no UI; It does what it needs to do without the help of a user. It could be as simple as canceling the app or have multiple dispositions based on the error. Non-interactive is necessary for com objects, and also for automated testing: an error is expected, and it needs to be logged and the test process should continue without interaction of a user.
    Here is a gotcha: If you have anything (even a comment) in an error event, that will override the ON ERROR error handler. This applies to subclasses too.
    Something that bugs me: After an error handler is invoked, subsequent errors are handled by the default vfp error handler. The ON ERROR command has no effect. -- CFK
    From Doug Hennigs Error Handling Paper:

    If type() is used anywhere in the error handling chain, you may not always get the correct error message. The reason is that type() uses some of VFP’s error handling itself, and as a result, the contents of message() can be overwritten if the variable or property checked with type() doesn’t exist. This explains “variable not found” messages your error hander may sometimes report when the error was in fact caused by something else. In VFP 98, use vartype() when possible; it’s faster than type() and avoids this problem.

    See Error Handling, On Error, Error Event Strategy
    Category Developer Productivity, Category Error Handling, Category Exam 70-155 Hot Topic
    Contributors: Carl Karsten
  • ( Topic last updated: 2014.05.09 10:47:33 AM )