ErrHandler update

[Michael Asherman]

An updated version of my generic VFP error handling classes and demo
application is now available. This replaces the previous version of
5/23/01. See http://www.ideaxchg.com/ix08/d6/00000024.htm for a summary of
changes. (Sorry, but the online docs are still outdated.) The download
page is at http://www.ideaxchg.com/ix07/er/_sys/welcome.htm.

Mike Asherman

[Anders Altberg]

Michael
Will you be revising your system when VFP8 is released to make use of TRY -
CATCH - FINALLY - ENDTRY and THROW?
-Anders

"Michael Asherman" <m...@ideaxchg.com> wrote in message
news:#dMue1HdCHA.1700@tkmsftngp10...

[Michael Asherman]

Hi Anders,

I'm not sure when I'll get around to it, but eventually I expect to make
appropriate adjustments to accommodate the new error handling features of
VFP 8. Maybe I'll wait until Doug Hennig explains things to us with another
of his excellent articles :) I still haven't figured out the point of the
FINALLY clause!

I suppose my own approach could be characterized as a sort of TRY/CATCH
scheme, so I don't have an urgent need for this particular VFP 8
enhancement. My approach also tends to avoid the possibility of nested
errors, so I don't yet see the need for VFP 8's new nested error handling
capabilities in my own applications.

It certainly makes sense to extend the ErrHandler classes in such a way as
to support all available error handling mechanisms, but their evolution will
be probably be driven the practical requirements of the applications I
happen to be working on. I'm not doing this as a theoretical exercise.

Mike

"Anders Altberg" <pra...@telia.com> wrote in message
news:ODI32tKdCHA.1540@tkmsftngp10...

[Nancy Folsom]

On Wed, 16 Oct 2002 19:07:48 -0400, "Michael Asherman"
<m...@ideaxchg.com> wrote:

>I'm not sure when I'll get around to it, but eventually I expect to make
>appropriate adjustments to accommodate the new error handling features of
>VFP 8. Maybe I'll wait until Doug Hennig explains things to us with another
>of his excellent articles :) I still haven't figured out the point of the
>FINALLY clause!

The Finally is just guaranteed to occur regardless of whether there
was an error or not, after any other error handling occurs, and after
any errors that the catch might re-throw have run. It's optional. What
it would be used for is highly dependent on what the try-catch is
doing.

Nancy Folsom--FoxPro MVP
Author of _Debugging_Visual_FoxPro_Applications_
http://www.hentzenwerke.com/catalogavailability/debugvfp.htm

In order to best serve the community, please post to the public
forum. I only reply to private requests for support from clients.

[Michael Asherman]

Thanks for the explanation Nancy, but I must be a bit dense. If the FINALLY
code is executed in either case, why is it necessary to have a special
clause for it? Why not simply put the same piece of logic in the code that
follows the whole TRY ... ENDTRY construct?

Mike

"Nancy Folsom" <nancy_...@hotmail.com> wrote in message
news:497squgpavbqchr8t...@4ax.com...

[gerry]

i haven't seen the VFP8 implementation of structured exception handling but
generally if an exception occurs and is not handled , or is handled and
re-thrown by the handler , the code after the try block never executes.
finally ensures that code will be executed whether an exception has been
thrown or not. this is generally used to release allocated resources such
as open files

subroutine xxx

open some files
try {
some code
} catch (someException) {
specific exception handling
re-throw exception
} finally {
* will execute whether or not exception has occurred
close files opened above
}
* will only execute if :
* - no exception is thrown
* - exception is thrown but handled and NOT rethrown
* will not execute if :
* - exception is thrown and not handled
* - exception is thrown and handled and rethrown
* -> note the finally block does not constitute an exception handler
more code
endsub

"Michael Asherman" <m...@ideaxchg.com> wrote in message

news:eZC1NcYdCHA.2440@tkmsftngp08...

[Nancy Folsom]

On Wed, 16 Oct 2002 22:47:54 -0400, "Michael Asherman"
<m...@ideaxchg.com> wrote:

>Thanks for the explanation Nancy, but I must be a bit dense.

Not at all. Try/Catch made sense to me, but just try me on explaning
the difference between implementing ienumerable and ienumerator. Which
I'm doing for the next issue of VFUG newsletter.

>If the FINALLY
>code is executed in either case, why is it necessary to have a special
>clause for it? Why not simply put the same piece of logic in the code that
>follows the whole TRY ... ENDTRY construct?

I see that Gerry explained it. The stuff after the Try/Catch block
won't run if there's an error. So, if there's something you have to
have execute regardless of error, then use finally.

FWIW, my experience with it, such as it is, is with C# and not VFP. We
should recognize, IMO, that it's a C++ concept that's now been adapted
in VFP. To that end it may not come about that the best practice will
be the same as it is for C++ or VS.NET. I don't have any definite
guidelines, but just as an example of how it might be a different
flavor for a Fox developer is this hint. A C++ developer I was talking
to was aghast to learn just how much recovery and default behavior we
code as FoxPro developers. Part of that, if not all of that, comes
about, IMO, because Fox uses variant variables and has the notion of
optional parameters.

[Allen]

++++++++++++++++
From VFP 8 Beta:
++++++++++++++++

exception 5 levels deep
*
TRY
[TryCommands]
[CATCH [TO VarName] [WHEN lExpression]
[CatchCommands]]
[EXIT]
[THROW eUserExpression]
[FINALLY
[FinallyCommands]]
ENDTRY

Parameters
TRY
Indicates the beginning of the TRY...CATCH...FINALLY structure.

TryCommands
Specifies statements where an error might occur.
If an error occurs, Visual FoxPro stores a reference to an Exception object
in the VarName memory variable. Program execution then proceeds directly to
the CATCH statements. If no error occurs, program execution proceeds to the
FINALLY statements.

CATCH
Indicates the beginning of a CATCH block, which handles the appropriate
error. You can specify a CATCH statement without arguments, which evaluates
to CATCH WHEN TRUE (.T.).

TO VarName
Specifies an optional memory variable that stores a reference to an
Exception object, which is automatically created if an error occurs in the
TRY block. VarName can only be a simple memory variable, not an object
property reference.
You can explicitly set VarName to any value in the TRY...CATCH…FINALLY
structure. The value does not change as long as another CATCH statement does
not run, which resets VarName to NULL.
VarName can have local, public, or private scope, which depends on how the
variable was previously declared. If VarName has not been previously
declared, it has private scope. The Exception object created has the same
scope as VarName. When VarName goes out of scope, is released, or is reset,
the Exception object is also released.
When a CATCH TO VarName clause runs, Visual FoxPro always sets the VarName
memory variable to a new Exception object regardless of its previous
setting, though VarName retains its scope. Therefore, the contents of
VarName are always overwritten regardless of what it previously referenced.
If a WHEN clause exists, and it evaluates to False (.F.), Visual FoxPro
releases the Exception object and resets the VarName to NULL. You can test
whether VarName is set to a type or to NULL by using the VARTYPE() function.

WHEN lExpression
Specifies an optional expression that is evaluated when the program
encounters the CATCH statement. The expression must evaluate to True (.T.)
in order for the corresponding catchCommands to run.
The lExpression parameter can contain a reference to the VarName Exception
object so that you can query the resulting error and handle it accordingly.

Allen, From Shanghai.

[Michael Asherman]

Thanks for the clarification, Gerry. I guess the way I would think of it,
FINALLY handles unconditional cleanups that are "local" to the TRY block,
i.e. steps that would neither be performed later in the program nor in a
more global error handler.

Mike

"gerry" <ge...@hotmail.com> wrote in message
news:ulvaQDZdCHA.776@tkmsftngp08...

[Nancy Folsom]

On Thu, 17 Oct 2002 12:30:02 -0400, "Michael Asherman"
<m...@ideaxchg.com> wrote:

>Thanks for the clarification, Gerry. I guess the way I would think of it,
>FINALLY handles unconditional cleanups that are "local" to the TRY block,
>i.e. steps that would neither be performed later in the program nor in a
>more global error handler.

Hm. Not quite. Yes, the FINALLY is local to the TRY, but the code it
in it will executed, even if the TRY didn't throw an error. So, you
wouldn't put code in there *just* to finish up from an error. Only a
QUIT or CANCEL will stop a FINALLY from executing. (Or, IIRC, if an
error occurs in the Catch code.)

[Michael Asherman]

Hi Nancy,

I'm sure your demystification of the latest esoteric features will be
appreciated.

You may well be right that best practices in VFP error handling will be
different from those of other languages. I wouldn't lay the blame quite so
narrowly as on VFP's lack of strict data typing or its support of optional
parameters, though. More generally, it's VFP's dynamic-ness ("dynamicity"
?) that leads to so many possibilities for errors. Not that I would want to
give up VFP's greater flexibility! Another contributing factor is the many
basic, error-prone commands that provide no simple, direct way to obtain an
error indicator. I would cite the USE command as a prime example of this.

Mike

"Nancy Folsom" <nancy_...@hotmail.com> wrote in message

news:v8hsqug0fmkp1156p...@4ax.com...

[Michael Asherman]

Thank you, Allen. That's the most complete documentation I've seen so far.
I'm still scratching my head as to the situations where my ErrHandler
classes need to employ VFP8's TRY ... CATCH. I guess I'll cross that bridge
when I come to it... or wait for the movie. :)

Mike

"Allen" <zyg...@21cn.COM> wrote in message
news:eM2aPXedCHA.1820@tkmsftngp12...

[Nancy Folsom]

On Thu, 17 Oct 2002 12:52:10 -0400, "Michael Asherman"
<m...@ideaxchg.com> wrote:

>I'm sure your demystification of the latest esoteric features will be
>appreciated.
>
>You may well be right that best practices in VFP error handling will be
>different from those of other languages. I wouldn't lay the blame quite so
>narrowly as on VFP's lack of strict data typing or its support of optional
>parameters, though.
>More generally, it's VFP's dynamic-ness ("dynamicity"
>?) that leads to so many possibilities for errors.

It wasn't accussatory, and we're saying the same thing, actually. Nor
do I think VFP is more or less prone to programming errors. After all
the TRY CATCH has been around in C++ at least.

[Michael Asherman]

Yes, I think I understand. I didn't say local to the CATCH, but local to
the TRY. I.e. the FINALLY clause corresponds to cleanups related to the
action that is performed in the TRY step, whether it succeeds or not.
Correct?

More typically, I would expect that such cleanup steps would not be so
tightly coupled to the initial TRY action. E.g. one might open a table
within a TRY block, but the closing could take place at some distant point
in the program logic, not immediately after the opening. Thanks to you and
the others who have provided further clarification about this.

Mike

"Nancy Folsom" <nancy_...@hotmail.com> wrote in message

news:9vptqucedid8rbus6...@4ax.com...

[Anders Altberg]

The FINALLY block is always executed. You can use IF VARTYPE(oException)='O'
to separate code to execute in case of an error. But code in the CATCH block
only runs in case of an error. It lets you determine the order in which
things get done after the error.
-Anders

"Michael Asherman" <m...@ideaxchg.com> wrote in message

news:#50yUofdCHA.2008@tkmsftngp08...

[Anders Altberg]

There's a doc bug there I think. It should be [THROW [eUserExpression]]
-Anders

"Allen" <zyg...@21cn.COM> wrote in message
news:eM2aPXedCHA.1820@tkmsftngp12...

[Michael Asherman]

I get it. Thanks again, Anders.

Mike

"Anders Altberg" <pra...@telia.com> wrote in message

news:e4baZPhdCHA.2556@tkmsftngp11...

[Fernando D. Bozzo]

Hello all:

I have onequestion about this:

Where in the code will be possible to put this TRY/CATCH, in the Error
event? or only in PRG's?

Thanks,

Fernando D. Bozzo

"Anders Altberg" <pra...@telia.com> escribió en el mensaje
news:evSedPhdCHA.2556@tkmsftngp11...

[Anders Altberg]

In any code, program code or object method code. The error event is another
level of error handling and can be coordinated with Try EndTry blocls.
-Anders

"Fernando D. Bozzo" <fdb...@lycos.es> wrote in message
news:eYjdc2SeCHA.2612@tkmsftngp09...

[Rick Bean]

Fernando,
It appears that in the beta, it'll work in any Progam (.PRG) or Method
(.PRG, .SCX, .VCX) code.

Rick

"Fernando D. Bozzo" <fdb...@lycos.es> wrote in message
news:eYjdc2SeCHA.2612@tkmsftngp09...

[Fernando D. Bozzo]

Thanks Anders & Rick:)

"Fernando D. Bozzo" <fdb...@lycos.es> escribió en el mensaje
news:eYjdc2SeCHA.2612@tkmsftngp09...