Error handling. "ON ERROR"

[AndrewMozley]

I am working on an application where run-time errors do not seem to be being reported.

To check this out, I have included these instructions in a cmd.click() method (Note : Variable ‘Wrong’ is undefined):

ERROR 1
Right = Wrong

I have not been able to track down the error handler (not aware that it is not the standard error handler, but clearly something has changed). I believe that both of these last two instructions should cause run-time errors.

Have expanded the code to :

ON ERROR DO Thisform.TempError WITH ERROR(), MESSAGE(), MESSAGE(1), PROGRAM(), LINENO()
ON ERROR DO Thisform.TempError(ERROR(), MESSAGE(), MESSAGE(1), PROGRAM(), LINENO( ))
SET STEP ON
ERROR 1
Right = Wrong

The method Thisform.TempError() does exist. It starts with a SET STEP ON instruction. At run-time no error is reported. If I single-step after that first SET STEP ON, the message “Source not available” appears in the debugger, but the program then continues happily (but still does not report errors) - there are several!

I would be grateful for specific guidance about how to correct my program so that VFP can report back to me the errors in my code.

Thanks. Andrew

 

[Dan Freeman]

Are you inside a Try/Catch?

 

[Dan Freeman]

BTW, the best information about VFP's error handling are in three white papers on Doug Hennig's web site:

http://www.quickmeme.com/news/?p=5365

Search for the words "Error Handling" once you get there.

 

[Dan Freeman]

Not sure where that URL comes from. Think it's time for a virus scan!

Anyway, it's

http://www.doughennig.com,

click White Papers, and search for "Error Handling".

 

[Olaf Doschke]

THISFORM is not something you can use for error handling. Think about scoping.

ON ERROR like ON KEY LABEL and ON ESCAPE executes the statement following that definition outside of the current scope. Imagine the line executed being compiled into a new PRG file. It has only access to public variables and it can call functions or procedures in PRGs known by SET PROCEDURE, no more, no less.

As said in the help topic: "Typically, ON ERROR uses the DO command to specify an error-handling procedure or program". If you want to handle an error of a class or form, do so in the Error METHOD of that class or form.

Bye, Olaf.

 

[AndrewMozley]

Thanks, Dan

No. I do not believe that I am in a TRY . . . CATCH, certainly not in this method. In fact the exact code of cmdAddclick() is :


LOCAL lFormatname, xlsLocation, lxltLocation, lFormatdesc, lStyle, lFolderOut
WITH Thisform
* Nov 2014. Errors do not seem to be being reported. Don't know why not.
ON ERROR DO Thisform.TempError WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )
ON ERROR DO Thisform.TempError(ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( ))
SET STEP ON
ERROR 1
right = wrong
. . .


I am clearly making some simple mistake!

 

[Dan Freeman]

It would probably be in the code that calls this form.

I'd use Code References to locate all instances of ON ERROR in the project. Someone probably turned off error handling with ON ERROR * (or ON ERROR DO NOTHING where nothing.prg does, um, nothing). SOMETHING is subverting event processing.

 

[Mike Lewis]

Andrew,

First, the fact that you are seeing "Source not available" in the debugger is not directly related to the presence or absence of error-handling. It usually means either that the source code is out of sync with the object code, or that the source code is literally not present. The usual solution is to make sure the source code is present, and then explicitly compile it with a COMPILE command.

Similarly, SET STEP ON is not directly related to error-handling. Rather it is used to invoke the debugger.

Next, your error-handler needs to be a PRG file, not a form. The main reason for that is that you can't guarantee that the form will be running when the error occurs.

You should put this command near the start of your main program:

[tt]ON ERROR DO ErrorRoutine WITH ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( )[/tt]

Then create ErrorRoutine()- or whatever you want to call it - which should start like this:

[tt]PROCEDURE ErrorRoutine
LPARAMETERS tnErr, tcMess, tnMess1, tcProg, tnLine
[/tt]
The routine should do the following:

1. Report the error to the user.

2. Create some sort of error log for the developer's benefit.

3. Close the application.

Once that's in place, any error at run time will invoke the routine, and you (or the user) should see the notification of the error. You can also force the error routine to be invoked by executing[tt] ERROR <error number> | <message>[/tt].

Only execute the ON ERROR code when you are running from an executable. If you are in the development environment, it is better not to have the error-handler in place, but instead to use the built-in error-handling, which essentially gives you a Suspend / Cancel / Ignore option. That way, you can ignore trivial errors during development, or choose Suspend, and then invoke the debugger.

I hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you everyone.

I see what I was doing wrong. I had incorporated into a form some controls from a previous application; these were using a different framework; as far as I can see these controls on initialising were resetting the link to error processing and no doubt doing other things.

The form is being rebuilt using the standard controls of the application, and I believe this will resolve the problem.

Thank you also for the guidance on the location and scope of the error handler.

 

[Olaf Doschke]

That may explain something, but your own setting of ON ERROR explains the behavior alone.

1. only the last setting of ON ERROR is used, the first one is overriden.
2. The setting is applied but in itself leads to an error as you reference THISFORM. All errors finally lead to display of the error "THISFORM can only be used within a method".

To see, execute this put into a PRG:

ON ERROR DO Thisform.TempError(ERROR( ), MESSAGE( ), MESSAGE(1), PROGRAM( ), LINENO( ))
Error 1

The same happens if you put this into the init method of a form. That's because ON ERROR in itself then is running in the form init, yes, but that's not making the DO execute, it's just defining in case of an error the DO is executed. It's executed outseide of the context of any running object, so THISFORM is nothing you can use in the definition of what happens in the case of an error, no matter if you do ON ERROR in a form, in a prg or in the command window.

And obviously Error 1 is "File does not exist", not "THISFORM can only be used within a method". The real error is "masked" by the error you have in your ON ERROR definition and it only shows up when an error occurs, as the ON ERROR command itself is not testing, whether the code you want to get triggered will work. It's a good idea to test error handling with ERROR 1 or any other valid error code, therefore. Or any wrong code. And as you do test this right after you ON ERROR definition, you must have had error "THISFORM can only be used within a method", which simply points out the wrong ON ERROR definition.

Bye, Olaf.

 

[Mike Lewis]

Andrew, I wonder if you were using THISFORM.tmpError as your error-handler because you wanted it to deal with errors that were local to the form. In other words, you have a standard global error-handler, but you want to override it just for errors that occur in the form.

If so, then a better solution would be to use the form's Error method. In fact, that's what it's for. That said, I never use it myself, and I don't see any benefits in doing so, but it might be something to keep at the back of your mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads