CatchING an In-Top-LevelForm error

[memarques]

Hi there.

I’m not able to determine “where” an exception occurred in a system. As an example I create a simulation of this:

I have a “master” form say FormPrinc “As Top-Level Form”. In config.fpw I have a screen=off.

In this form I have 2 command buttons each one calls secondary form (say Form1 and form2) defined as “In Top-Level Form”

And my “main program” is:

[tt]TRY

DO FORM formprinc NAME formprinc
READ EVENTS
​

CATCH TO oErr

CRLF = CHR(13)+CHR(10)
cStr = "Error Catch Test" + CRLF + ;
"[ Error: ] " + STR(oErr.ErrorNo) + CRLF + ;
"[ LineNo: ] " + STR(oErr.LineNo) + CRLF + ;
"[ Message: ] " + oErr.Message + CRLF + ;
"[ Procedure: ] " + oErr.Procedure + CRLF + ;
"[ Details: ] " + oErr.Details + CRLF + ;
"[ StackLevel: ] " + STR(oErr.StackLevel) + CRLF + ;
"[ LineContents: ] " + oErr.LineContents
MESSAGEBOX(cStr )
​

ENDTRY

TRY

formprinc.release​

CATCH
ENDTRY
[/tt]

My problem is when an error occurs in form1 or form2 I can’t determine where the error happened. I would like to close the “error form” showing an error message and be able to continue the system, closing only the problematic form.

In the “main” form I call the child form this way (thought a command button):

[tt]TRY

DO FORM form1
​

CATCH

MESSAGEBOX("Error Form1")
​

ENDTRY[/tt]

Of course this “CATCH” only occurs if there is an error in the INIT of the form. Any other error that “may occurs” during the FORM’s operation is “CATCHED” by the main Program (because the child forms are “In Top-Level Form”, but I can’t know from where.

Any suggestion how I can know where (in witch child form) the error occurred?

I’m leaving a sample here:

http://www.peek.com.br/TestesMDI.zip

Thx
Mauro

 

[Olaf Doschke]

Putting TRY..CATCH on code calling something is a bad idea, the more so, if that is you main form. You now only get an exception of the DO FORM line. That's not what structured error handling is meant for, no.

You do this with the traditional general error handling via ON ERROR. The new TRY..CATCH is not the successor of ON ERROR, nor is the objet.Error() event obsolete. You can and should combine all these concepts.

For example the general error handling helps you better see where exect errors happen, additional to LINENO() and PROGRAM() you can pass in as parameters in ON ERROR, you can use ASTACKINFO. TRY..CATCH sucks back the excution to main.prg and doesn't give you mich info. Even though you may try ASTACKINFO in the catch block, the structural error handling should only be used for short code snippets with a range of some expected exceptions, not as general error handling.

Bye, Olaf.

 

[memarques]

Olaf

Ok, I understood the concept that you explained. I’ll try to change the way that I “try” to handle the errors.
Regards
Mauro

 

[Mike Lewis]

I completely agree with Olaf. TRY/CATCH/ENDTRY is called local error-handling, for a good reason. It is designed to trap errors occurring in a single command or a small piece of code. A typical use for it is the case where you are trying to open a table, and you want to deal with the possibility that the table cannot be opened for some reason.

In most cases, what you need is a global error-handler. That's what ON ERROR is all about.

One other point: When you are testing your program in the development environment, it's better not to have an error-handler in force. Or, rather, to rely on VFP's built-in error-handler. When a runtime error occurs, this gives you a useful dialogue, from which you can choose to cancel or suspend the program, or ignore the error. If you choose to suspend, you then have the full power of the debugger and other development tools to trace and correct the error.

But those choices are not appropriate when the user is running the program from an executable. In that case, you want to halt the program. More importantly, you want to log the error in some way, such as writing the details to a text file or automatically emailing them to the developer. It is not enough to display the error details in a message box, as that does not give the user a useful way of communicating the details to the developer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

VFP is a robust program so error handling should be similarly robust.

I've always appreciated Doug Hennig's approach (

http://doughennig.com/papers/Pub/errorh.pdf),

although it was written before we got TRY/CATCH, which makes the error soup more complicated in some ways and easier in others.