Foxpro On Error Command
resources Windows Server 2012 resources Programs MSDN subscriptions Overview Benefits Administrators Students Microsoft Imagine Microsoft Student Partners ISV Startups TechRewards Events Community Magazine vfp on error resume next Forums Blogs Channel 9 Documentation APIs and reference Dev centers vfp on error example Retired content Samples We’re sorry. The content you requested has been removed. You’ll be auto redirected in 1 second. Using Visual FoxPro Developing Visual FoxPro Applications Testing and Debugging Applications Testing and Debugging Applications Handling Run-Time Errors Handling Run-Time Errors Handling Run-Time Errors Creating Bookmarks and Task List Shortcuts Testing a Project Handling Run-Time Errors Structured Error Handling Debugging Before Bugs Exist Isolating Problems TOC Collapse the table of content Expand the table of content This documentation is archived and is not being maintained. This documentation is archived and is not being maintained. Handling Run-Time Errors Visual Studio .NET 2003 Run-time errors occur after the application starts to execute. Actions that would generate run-time errors include: writing to a file that doesn't exist, attempting to open a table that is already open, trying to select a table that has been closed, encountering a data conflict, dividing a value by zero, and so on. At times, errors occur when users run your application. You can call your own error-handling routine by including ON ERROR. Typically, ON ERROR uses a DO command to run a routine that handles the error, as in: Copy ON ERROR DO My_Error If your application contains no error-handling routines when an error occurs, the application pauses and Visual FoxPro displays an error message with the following options: Cancel If a user chooses Cancel, Visual FoxPro immediately stops running the application and returns control to the system. Ignore If a user chooses Ignore, Visual FoxPro ignores the line that caused the error and continues to the
program execution resumes on the line immediately following the line that caused the error. However, if the error-handling procedure includes RETRY, the program line that caused the error is executed again. If the command specifies a procedure to execute when an error occurs, you can use ERROR(), MESSAGE(), LINENO(), and PROGRAM() to pass the error number, the error message, the program line number, and the program name to the procedure. This information can be used to correct the cause of the error. Remarks: When an error occurs during program execution, Visual https://msdn.microsoft.com/en-us/library/aa975615(v=vs.71).aspx FoxPro executes the command you specify with ON ERROR. Typically, ON ERROR uses DO to execute an error-handling procedure. Use ON ERROR without a command to restore the default Visual FoxPro error handler. ON ERROR procedures cannot be nested. If ON ERROR is issued within an ON ERROR procedure, the default Visual FoxPro error handler is restored. The last sentence in the above quote (about http://fox.wikis.com/wc.dll?Wiki~OnError nested "on error" statements) is untrue, at least in VFP 7. For example, in VFP 7, the following code works: local sPreviousErrorHandler m.sPreviousErrorHandler=on("error") && Save the previous error handler. on error HandleError(m.sPreviousErrorHandler) && If there's an error, call our local error handler. use nonexistent_table && Trip our local error handler. function HandleError(sPreviousHandler) messagebox("Ouch! Returning to previous error handler.") on error &sPreviousHandler endfunc Notice that the "on error" command inside of the "HandleError" function is nested. Even the following, more obviously nested command works: on error on error return && Don't return on the first error, but do on the second one. When in Development Mode, it's always useful to handle errors differently than in Production Mode. In Production Mode, typically your ON ERROR should trigger modal dialog with the error, a suggestion for resolution or to contact the developer, and an OK button (among others). In Development Mode, your ON ERROR should bomb you back into your development environment, or trigger a different custom dialog which includes, at minimum, ok, cancel, and debug buttons. This allows easy access to the environment for debugging errors. There is a nifty lightweight and f
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. http://www.sweetpotatosoftware.com/spsblog/2008/11/24/ProfessionalErrorHandlingForVFPApplications.aspx In either case, this type of error handling is usually woefully inadequate. Not onlyare these approachesof 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 HandlingAt Southwest Fox 2008, I presented a session entitled "Creating on error 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 takewhen implementing error handling in your Visual FoxPro applications.There is sure to be room for improvement, but the state informaiton it gathers is pretty extensiveand I've found that most users find the error screen (see vfp on error screen shots below)to be non-threatening/reassuring when exceptions arise. How to Use the Error HandlerIn order to implement the error handler in your own applications, you'll need the functions and the ON ERROR command thatare in the main.prg of the sample application (provided in the download below). You'll also want to include the issues.scx formin 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 CreditMost of the code that you'll find in the main.prg for collecting error information came fromthe book "Special Edition Using Visual FoxPro 6". And, the