Error in error handler

[foxdbs]

Hi. If there is an error in code, and error procedure starts, is there a possibility to disable error messages for next errors (i.e. for errors inside the error procedure)?

I know that starting from VFP8 Try/Catch can be used. But in VFP7?

 

[Mike Gagnon]

Try using

[blue]On error[/blue] *

If you use this, it will skip by the error.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[StewartUK]

Generally speaking if you get an error in your global ON ERROR handler, VFP will display its default Cancel, Retry, Ignore dialog box.

I don't know about using TRY...CATCH.

You could always give it a go - create a new temporary ON ERROR routine with a try...catch around a line that tries to print a non-existent variable name.

In the command window, execute an ON ERROR command and then do something that will cause an error and see what happens.



Hope that helps,

Stewart
PS If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Mike Lewis]

Foxdbs,

It is not a good idea to disable the error handler in the way you asked about. In general, any errors that occur in the error handler itself should be "un-handled", that is, you should leave VFP to deal with them.

The best thing to do is to debug your error handler especially carefully, so that no errors occur there. If an error does creep in, let VFP display its usual Cancel / Suspend / Ignore message, so that you can find it and fix it.

To achieve that, you don't need to take any special action. Just leave your code as it is.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[foxdbs]

Thank you for responses.

> Mike Gagnon: on error * doesn't work inside error handling code.

> Mike Lewis: yes. But I wait a little more from the error handling routine, f.e.: give info to the user in his current language, let write him his knowledges about the error, write error info into network table and e-mail the error. This functionality is 20% of full application functionality, which must be "especially carefully debugged".
My idea (VFP7) was to write error info somewhere and just leave the error handler. A timer can then look for new error infos and continue handle them. However in very time consuming code with no READ EVENTS/DOEVENTS commands, the timer will start much, much later. Other sollution could be to call second, independend .exe (RUN/ShellExecute).
However it is lot of additional work and if in VFP8 is the possibility to handle my problem with TRY/CATCH, then I will program nothing special in VFP7.

 

[Mike Lewis]

Foxdbs,

Sorry, but I think you are making this much too complicated.

If an error occurs during the error-handling process, it is up to you debug it as part of the development process, long before it reaches the user. There is no reason why the user should ever be aware of an error in the error handler. The best way for you to debug the error is to let VFP notify you of it, using the usual Cancel / Suspend / Ignore message.

Let me put it another way: the things you want from your error handler are completely standard. Every major app that I have worked on will write the error to a log, inform the user, etc (I could argue about letting the user enter information about the error, but that's not the main issue here). But I have never seen the need to resort to timers or other fancy tricks. Once the error handler has done its job, you should close down the app as rapidly and cleanly as possible. Surely you can write reasonably bug-free code to do that?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[rkolva]

I had a similar problem in that my error handler has a simple method to email error details. I don't recall the specifics but in one installation the required components were not on the machine and the app got stuck in a terminal loop trying to send the email. I inherited the app, the error handler is currently just a large function, and rather than doing a lot of sniffing work in the function to make sure everything I need to establish a connection is there I just set a flag property in a global object that indicates we are already in a current error event and then notify the user that the app will terminate. One of these days when I get time I will convert the error handler to an object and enhance it's recovery abilities but for the meantime I found that setting a flag works ok. Would something similar work in your situation?

Ralph