>>
>>Hm. Thank you for your suggestion.
>>I do not see where you catch / intercept unexpected erros? I mean O.k. I can remove all the events and put an outside TRY CATCH at the event loop. But then I remove every chance to debug a failure, because I can not retry / ignore / return (in debug mode, naturaly)
>>
>>Also debugging inside a TRY CATCH is a pain.
>>
>>I've never gone into deep with TRY CATCH because my error handler runs pretty well. I saw, as TRY CATCH was new, that there are problems with objects and outer TRY CATCH, but it never was needed. I removed some handlers that where run with the event by TRY CATCH for convenience and anything was fine.
>>
>>So I use the event / ON ERROR for the unexpected and TRY CATCH for the expected errors.
>>
>>Need to think about it...
>
>Well, there are some things that you can't do in the old way when using Try/Catch.
>
>I use it this way:
>
>- MAIN program have the most external Try/Catch, to trap "unexpected errors". Because they are unexpected, the safest way to procede is show a message and close the application. But this where allways the same.
>
>- Every form have a Try/Catch on the most important events of the interface (Normally Click) because on N-Tier the Interface shuld be the only that show messages to the user, so business logic THROW the error until it reach the Interface
>
>- Classlibs and programs have a try/Catch on most important methods, as processing or calculation, right there when it really add value to have it because a garbage collect is needed, in example.
>
>When you start adding this type of error trapping, you need to make a clear path for the error to propagate, something that programmers normally don't care (you can see it on the forums, many people don't have error routines, because they think that the code is one thing and the error trapping is another thing, and sometimes unnecesary because is loosing time or don't know what to do with it)
>
>In certain methods that can be used in different ways and from distinct parts of the system, I use a special approach. Normally you have an error handler in a specific way, that is: you can allways THROW the error to a higher level or you can trap it and return an error code. But sometimes you need both options, depending on the use case. For this special case, I use this approach:
>
>

>PROCEDURE MyProc
>   LPARAMETERS tl_RethrowError, toEx as Exception, <more_params>
>
>   TRY
>      ERROR "Intentional error"
>   
>   CATCH TO toEx
>      lnCodError = loEx.ErrorNum
>      loEx.UserValue = loEx.UserValue + "some useful debug data"
>      IF tl_RethrowError
>         THROW
>      ENDIF
>      IF _VFP.StartMode = 0 THEN
>         SET ASSERTS ON
>         ASSERT .F. MESSAGE "some message"
>      ENDIF
>
>   FINALLY
>      *Garbage collect here
>   ENDTRY
>
>   RETURN lnCodError
>ENDPROC
>

>
>With this code you can decide what type of behaviour you want from the OUTER side:
>
>- If you need to control the error in place and return the code, then you pass the extra parameters ".F., @loEx"
>
>In example:
>

>loEx = NULL
>lnCodError = MYProc( .F., @loEx )
>IF lnCodError > 0 THEN
>   *<local error management>
>ENDIF
>

>
>- If you want to THROW the error to a higher level, then you pass the extra parameter ".T."
>
>In example:
>

>DO MYProc WITH .T. => If error occurs, is raised to a high level CATCH
>

>
>The BEST thing of Try/Catch, and something that you don't have with ON ERORR, is the Garbage collection you can do when every level is closed, so every method cleanup his own environment (close tables, update log, etc) and pass the control to a high level Catch, that normally ends in the Interface. If you forgot to Catch in the Interface, then MAIN program Catch take care, CLOSING ALL and quitting the application. From the calling method you allways know what to do with a calling failure, because is part of the flow, but because encapsulation, you can do/assume nothing about the pending garbage that this method left behind, and now you don't need it because it is assumed that it cleared on it's own.
>
>Another nice feature of this error trapping is that it is easier to make Unit Testing (using FoxUnit in example)
>
>About debugging, you normally can use [set-next-statement] in the debugger (and sometimes you can't), and using allways RETURN at the end you can bypass the method code if needed, and use [set-next-statement] directly in the return.
>
>At first various things appear difficult because you evaluate with the knowledge of years with ON ERROR and Error event, but when you start using Try/Catch you change your mind and find different ways to do the same you did with the other error controllers.
>
>
>Regards.-

Something the like. A redesign I possibly like not to do with VFP anymore :)

And for me [set-next-statement] never worked in TRY CATCH. Possibly the debugger might allow in deeper methods with an outside TRY CATCH, I don't know.

Also after the catch it's hard to go back to the error. The rest, like garbage collection and so on I do where needed. What will not work under all circumstances is just to THROW up to main. I can not clear all objects from oustside. References and the like. They close up pretty well with the ERROR events.

I think for this special problem I alter the general handler (the one called by the ERROR events) and EVENTBIND to it.

Thanks.