# Monday, November 24, 2008

Same Old, Same Old
Far too often developers will either not implement error handling in their applications (allowing VFP's default error handler to prevail) or they will display a simple messagebox containing a few pieces of error information such as the values returned from Visual FoxPro's Error(), Message() and Lineno() functions. In either case, this type of error handling is usually woefully inadequate. Not only are these approaches of little use to the user, it is probably disconcerting (if not a little frightening) to them. The possible end result of these approaches: bugs go unreported, error information is not captured, and the user's overall confidence in the application is shaken.

A Possible Approach to Error Handling
At Southwest Fox 2008, I presented a session entitled "Creating a Professional VFP Application from Start to Finish" in which I showed the error handler that I use in a number of applications I have developed. That error handler is presented here as one possible approach you can take when implementing error handling in your Visual FoxPro applications. There is sure to be room for improvement, but the state informaiton it gathers is pretty extensive and I've found that most users find the error screen (see screen shots below) to be non-threatening/reassuring when exceptions arise.

How to Use the Error Handler
In order to implement the error handler in your own applications, you'll need the functions and the ON ERROR command that are in the main.prg of the sample application (provided in the download below). You'll also want to include the issues.scx form in your project and set the MyCompany, MyProduct, MyTechEmailAddress, and MyTechPhoneNumber properties of the issues form with your information. That's about all there is to it. I have included an FLL with the sample, but this is merely used to facilitate the transmittal of the error information via email. If you implement another method of transmission (such as a post to a Web Connection web application), then you needn't include the FLL.

To try the error handler out you can download the sample below and, after setting the issues form properties as noted above, simply build the project provided and run the executeable you've built. A form is provided that allows you to submit an issue manually as a customer would and also to throw an error to see how the error handler works in an exception situation.

Due Credit
Most of the code that you'll find in the main.prg for collecting error information came from the book "Special Edition Using Visual FoxPro 6". And, the code that is used to terminate the process after the exception has occured is from work done by Doug Hennig. So, special thanks to those two sources.

What's Next
Just have fun with the error handler and see if it's useful to you and your applications. In a perfect world, you'd find some way to improve it (add screenshot ability, refactor the code, etc.). If you do improve the error handler, I'd appreciate it if you would contact me and share the improvements you've implemented. Thank you in advanced to those of you that decide to do so.

Until next time... Visual FoxPro Rocks!

Download Error Handling Sample (approx. 41 KB)

Figure 1: The screen the user sees when an exception occurs.

 

Figure 2: Respecting the user's privacy, they are allowed to view what the error report contains before it is sent.

 

Figure 3: The screen also allows the user to provide additional information before submitting the error report.

Monday, November 24, 2008 11:07:36 AM (GMT Standard Time, UTC+00:00)  #    Comments [4]
Monday, November 24, 2008 2:27:34 PM (GMT Standard Time, UTC+00:00)
Thank you very much Craig!!!
Monday, November 24, 2008 11:10:03 PM (GMT Standard Time, UTC+00:00)
Very nicely done Craig. It is similar to the work the late Drew Speedy did in his framework, which I have used for years with this wonderful feature. It saved me countless hours and grief with the detailed error info I received.
Tuesday, November 25, 2008 7:30:19 PM (GMT Standard Time, UTC+00:00)
Very nice!

Implemented on a trial basis and already pointed me in the right direction.

Would appreciate your thoughts on implementing the
"ASTACKINFO(ArrayName)" as additional information. If you think it would be feasible, what would you recomment to capture.
Ron Haugen
Wednesday, November 26, 2008 12:30:15 AM (GMT Standard Time, UTC+00:00)
Hi Ron,

ASTACKINFO() would be a very nice addition. I'd recommend capturing everything except for the current stack level (since that would always be the error handling procedure. Something like...

* Next report on the stack
LOCAL lnStackCounter, lnStackLevels
LOCAL ARRAY laStackInfo[1]
m.lnStackLevels = AStackInfo(laStackInfo)
? 'Call Stack:'
FOR m.lnStackCounter = (m.lnStackLevels - 1) TO 1 STEP -1
? 'Level: ' + TRANSFORM(laStackInfo(m.lnStackCounter,1))
? 'Program Name: ' + laStackInfo(m.lnStackCounter,2)
? 'Mod/Obj Name: ' + laStackInfo(m.lnStackCounter,3)
? 'Mod/Obj File: ' + laStackInfo(m.lnStackCounter,4)
? 'Line Number: ' + TRANSFORM(laStackInfo(m.lnStackCounter,5))
? 'Source Line: ' + laStackInfo(m.lnStackCounter,6)
ENDFOR
Release laStackInfo, lnStackCounter, lnStackLevels
All comments require the approval of the site owner before being displayed.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Enter the code shown (prevents robots):

Live Comment Preview

 

Archive

<March 2010>
SunMonTueWedThuFriSat
28123456
78910111213
14151617181920
21222324252627
28293031123
45678910