>I just discovered something extremly severe in regards to a specific bug. For years, I had an error handler which was working fine. Tonight, I discovered a specific situation where this is not the case.
>
>At the end of my error handler, I have RETURN TO ProcessHit. This is within WWC, where after I have logged the error, I return the control back to that method. So, wherever the code was when the error occurs, after the error handler is completed, the continuation of code of the method where the error occured is stopped as the RETURN TO ProcessHit redirects to a upper method.
>
>I never had any problem with that logic. This is also what is mentioned in WWC when using our own error handler. The problem is not there. As I said, it was working fine for years.
>
>So, basically, here is scenario one from a specific function down the code:
>
>

>LOCAL lcVariable
>lcVariable='x'
>lcNewVariable=z
>MESSAGEBOX('test')
>

>
>This will generate an error as z doesn't exist. So, what happens is that the error handler kicks in, log the error and return to somewhere else. So, the messagebox never fires.
>
>So, whatever the type of error is this is what will happen. That has worked perfectly until now.
>
>Scenario two:
>
>

>SELECT Contact
>COUNT FOR IRegion=lnRegion
>MESSAGEBOX('test')
>

>
>This will generate an error as lnRegion doesn't exist. In this particular situation, the RETURN TO ProcessHit never happens. After the error handler as completed, the control returns here to show the messagebox. The RETURN TO ProcessHit is for some kind of reason never done.
>
>I did several tests. If I do:
>
>

>SELECT * FROM Contact COUNT FOR IRegion=lnRegion
>MESSAGEBOX('test')
>

>
>That will work. The error handler will kick in, log the error, redirect to ProcessHit. The messagebox will never happens.
>
>What I have discovered is that the COUNT function of Visual FoxPro seems to lock a process in memory which will interfere with a redirection. This will only happen during a COUNT function. I never had that for other errors.
>
>I have to say this is the most ridiculous situation I ever saw in Visual FoxPro. What can I do in my error handler to disable the COUNT behavior on the error handler? I have CLOSE DATABASE ALL in my error handler right at the top and this happens also. It doesn't make any sense to me.

Hi Michel,

That certainly is a strange behavior I've never encountered, but it's possible you can beat the problem with something along the lines of my approach error handling. I realized that you may not be in a position to do a major rewrite, and I'm not sure how much of a change would be required, however the basic idea may be applicable.

Maybe you could adjust your error handler logic to capture the necessary info and set a flag, but let it return to the routine that encountered the error. Then let the logic of your method or function that does the COUNT immediately follow that step with a check to see if there was an error. If so, perform the appropriate context-specific error reporting, logging, abort, or whatever.

You can take a look at my ErrHandler forum at http://www.ideaxchg.com/ix07/er/_sys/toccontu.htm, where you'll find documentation and a downloadable demo, with source code.

Mike