>Hi All,
>
>I've had a nagging problem in the back of my mind for a long time.
>
>How do you guys handle problems like, a file not found on disk, a field not present in a database, a procedure returning .F. cos something's gone wrong - d'you get the idea? What use is it to a user to simply log a message "File not found", "Unexpected value" and then bomb out of the application. Is the answer just to log the error and then exit gracefully? Does anyone have any comments. I'd be interested to share any views.
>

These are all indications of errors that the end-user can't handle on their own; they might represent anything from a typo in code, to accidentally starting the app in the wrong directory by clicking on the .EXE in Explorer when it requires a shortcut to start, to accidental deletion or erasure of a necessary file, or file corruption.

The key here is to log the eerror with enough detail so that someone with more knowledge of the app - a more experienced user, the help desk, or the developer typically - canfigure out what happened. This means capturing the error, if not running with debug information suppressed, the actual line of code that VFP that smoked, the execution context, open tables, system variable settings, and in my case, configuration information that may be in my application object if it's there - and if not, let me know that oApp took a holiday!

I try to put handling for anticipated errors in the context of the object responsible for it - code in the Error method. I can check the error code, see if it's one that I just knew might happen here, and deal with it, and if not, pass it back up the chain of command. If it gets to the top and it's not something that can be dealt with in a generic fashion and safely resume the app, the main error handler then logs the gory details, trys to shut down gracefully, and exits. Doug Hennig's error handler it a good starting place for a top-level error handler.

The second thing that needs to be done is that the user has to report the error to someone. I get miffed at my users when I get a call from someone saying "I was cleaning out garbage files from the system, and there's this 6.9MB file ERRORLOG.FPT sitting here. Can I just go ahead and delete it?"; there's been a recurrent, minor error in code because I can't type, or didn't adequately test something I modified before releasing it, or J. Random FileDeleter Esq., the guy "cleaning out garbage files from the system", deleted something he shouldn't have a few weeks ago. It's important that errors get reported to someone for analysis, especailly the ones where the system blows up, but if you restart it and try again, the problem is gone. It means that there's something about the state of the app that isn't what was anticipated, and tracking down transient errors is tiome-consuming and difficult.

So yes, log the error, exit gracefully, and at least as important, remind the user to report it to someone who can do something about it.