Hi Charlie,

A TryCatchFinally object - what a cool idea! Unfortunately, what I would like to do is use TryCatchFinally logic throughout my application. Additionally there are times when I would like to nest TryCatchLogic within the same method or function. Given these scenarios and frequency of use, I think my code would quickly be overcome with zillions of TryCatchFinally subclasses.

My goal is to be able to place exception handling code within each routine vs. splitting routines into multiple ('sub')routines, subclasses, or using a series of global objects and/or flags to handle exceptions outside the original routine. Given the ability to return to a specific stack depth (and optionally exit the current loop construct at that point in the code), then I believe it is possible to closely match the TryCatchFinally functionality of C++, Java, C#, and VB.NET using the existing VFP product.

By the way, the TryFinally construct (without any catches) is also a powerful tool for developing clean code because it ensures that the code within the Finally block gets excuted no matter what. This eliminates the need to copy, paste and maintain duplicate 'cleanup' code that is often necessary when prematurly existing a loop or routine.

Here's what I would like to do (semanitcally) within VFP using your example.

procedure MyTest( FileName )

  TRY
    use (m.FileName) alias TEMPALIAS exclusive
    ... other code ...

  CATCH oError.Number == X
    wait window 'Sorry'

  CATCH oError.Number == Y
    ... check for other exceptions ...

  FINALLY && optional
    * make sure table gets closed on function exit
    if alias() == 'TEMPALIAS'
      use
    endif
  ENDTRY

endproc

Thanks again for your feedback. Your idea of a TryCatchFinally class was very clever.

Regards,
Malcolm



>Hi Malcolm,
>I'm not sure I fully appreciate what you want to do. But here are my thoughts anyway. It seems like you want the ErrorHandler to return to a specific method in the stack. That seems like a job for the object itself, not some application wide ErrorHandler.
>Why not have a TryCatchFinally object?
>

>Example:
>oTest = NEWOBJECT("MyTest")
>oTest.Try("MyTableName")
>RETURN
>
>DEFINE CLASS MyTest AS TryCatchFinally
>   PROCEDURE Try (FileName)
>       USE (m.FileName) EXCLUSIVE
>       RETURN DODEFAULT()
>   ENDPROC
>
>   PROCEDURE Catch
>      IF This.oError.Number = X
>         WAIT WINDOW "Sorry"
>      ELSE
>         * Do Nothing.
>      ENDIF
>   ENDPROC
>ENDDEFINE
>
>* Abstract Class.
>DEFINE CLASS TryCatchFinally AS Relation
>   oError = .NULL.
>
>   PROCEDURE Try()
>      * Write the Try block here in the subclass.
>      RETURN ISNULL(This.oError) AND This.Finally()
>   ENDPROC
>
>   PROCEDURE Catch()
>       * Write the code to run when the Try fails.
>   ENDPROC
>
>   PROCEDURE Finally()
>      * Write code to run when all is well.
>   ENDPROC
>
>   PROCEDURE Error ( nError, cMethod, nLine )
>      IF ISNULL(This.oError)
>         This.oError = NEWOBJECT('ErrorInfo')
>         This.oError.Save( m.nError, m.cMethod, m.nLine, This.Name )
>      ENDIF
>      This.Catch()
>   ENDPROC
>ENDDEFINE
>
>DEFINE ErrorInfo AS Relation
>Tag = "ErrorObject"
>ErrorNumber = 0
>ErrorMessage = ""
>ErrorCodeLine = ""
>ErrorLineNumber = 0
>ErrorProgram = ""
>ErrorName = ""
>
>* Pass the error facts and this method saves them to this objects properties.
>PROCEDURE Save (nError, cMethod, nLine, Name)
>* Error method of an object might create this error
>* object, then do a  This.oError.Save(m.nError, m.cMethod, m.nLine, This.Name)
>
>  WITH This
>   .ErrorNumber = IIF(VARTYPE(m.nError) = "N", m.nError, 0)
>   .ErrorMessage = MESSAGE()
>   .ErrorCodeLine = MESSAGE(1)
>   .ErrorProgram = IIF(VARTYPE(m.cMethod) = "C", m.cMethod,'')
>   .ErrorLineNumber = IIF(VARTYPE(m.nLine) = "N", m.nLine, 0)
>   .ErrorName = IIF(VARTYPE(m.Name) = "C", m.Name, '')
>  ENDWITH
>ENDPROC
>
>* Release this object.
>PROCEDURE Release
>   RELEASE This
>ENDPROC
>ENDEFINE
>

>>>While you're at it, could you write up a request for 'Try/Catch/Finally' functionality? I have never done any real-world work in a language that supported it...