>>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.

We have an error log, too. But making users around the world send the file to us regularly is another issue. They just send it when they have a *really big* problem that stops them to finish an important task. When we get it, we found there are many other *small* glitches hidden in our app.

I've been dreaming with a Tech Supp Web Site, where users can post their errors and logs (is anybody using Microsoft ATS web already?). But they don't even send the log via eMail...so making them connect to a web site and type something will be a hard thing...arghh.

Maybe creating an eMail using MAPI, attaching the error log and send it to the Outbox will be fine (but the log must be zipped, some computers are not connected to internet, bla bla bla). What's the best idea to retrieve errors from users?

Nelson