>Ok, I'll throw in my Euro 0.02,
>
>I agree with Rick that using the error event is not the best way of error handling. It is cumbersome for the reasons mentioned before.
>The only exception is using the WinSock ActiveX control. If you're not using the Error event, it will crash your executable but running out of memory when a connection error occurs.
>
>TRY CATCH however is not the silver magical bullet either. As mentioned the context of the error can get lost. It forces you to anticipate where errors can occur so you have to create a granular TC strategy.
>
>On the READ EVENTS I do not rely on a TRY CATCH, but on the ON ERROR error handler. Anything not anticipated in a TRY CATCH will be catched by the global error handler with full details of the call stack info. using a RETURN TO Start will make sure that currently executing code will be cancelled. This works remarkably well. Seldom our application crashes because of an programming error: The procedure is just cancelled and you can try again or do something else. In this strategy it is critical that if there are procedures that need cleanup in case of an error, are catched by a TRY CATCH though.
>
>When running in the VFP IDE for debugging, I disable the ON ERROR error handler, so that any error occurring outside of the TRY CATCH will enable you to debug directly on the spot of the error.

Reading this thread, I got an idea. The error thrown up indeed loses some of the info which was available in the context... and from that I mostly miss the stack at the time when error happened. Now this may be a way out...

aStackInfo(aa)
loExc.AddProperty("ast[1]", "")
DIMENSION loExc.ast(alen(aa,1), alen(aa,2))
acopy(aa, loExc.ast)
throw loExc