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.

Walter,


Debugging is also more of a challenge because it will never stop at the point of error, but only if you've got a breakpoint in the catch.





>Lutz,
>
>I wasn't suggesting you rip out all your code and replace it with TRY/CATCH. What I was pointing out that IF POSSIBLE that when you start from scratch or refactor code, using TRY/CATCH is a better approach. If you have a ton of code that already uses .Error() methods it's going to be very difficult to replace that code with TRY/CATCH because it's a completely different methodology (outside in vs. inside out) and as you point out that's a lot of effort that doesn't have a ton of benefit.
>
>But I don't agree that you can't get relevant error information without using .Error() methods - you can. No not an object and state (although you can still do memory dumps if you really want that). for the most part logging all of that is a good way to ensure nobody ever looks at the error logs :-). Full dumps of objects and memory should be a last ditch debugging issue, not a 'do all the time' issue for many reasons. There are more effective ways of doing this with tracing in your apps. 90% of the hard to find errors in applications tend to be logic errors not crash errors and those don't leave an error log in the first place...
>
>
>+++ Rick ----
>
>>Hi Rick,
>>
>>Hm. Why do I need the object?
>>The objects state gets logged - I simply put each and every property to the errorlog. This of the object that faild, it's super parent (normaly the form) and of the application object. Combined with DISP MEMO those are the common information I need to trace a strange error down. Also common information about cursors etc. I get a 100k errolog out of each error.
>>So it's mostly for errologing. If it was just for kill the app dead TRY CATCH would be fine enough.
>>I'm in a scenario with only a few customers with close contact, they report the errors well.
>>
>>So the error bubbles to a more sophisticated general errorhandler object if if no "handler" (nowadays there would be a TRY CATCH infront of the ERROR anyway) kicks in. It raises an information form and then returns to the main loop and this kills the app.
>>In debug mode it puts some error information to the screen (the basics) and allows to debug / suspend on the line of error. Only the special handlers are class specific.
>>This is all woking pretty well since VFP 5.0, so I don't touch this without a reason. (Only two reasons #1 major hickup, #2 somebody like to spend money for it)
>>
>>So that's why I vote for the combined thing. TRY CATCH where it is for the expected errors and the event / ON ERROR (there are procedures outside of objects) for the unexpected. TRY CATCH raises the unexpected part to the event as well. Not THROWING, I use RAISEEVENT from CATCH.
>>
>>The only problem all those years was the problem what ends up with this thread. It seems to me not that a big problem. But I do the TRY CATCH only to the point - what is a line or a very neat IF ELSE. Until now it looks like I kept my encapsualtion working so that no call out to a different object was handled by TRY CATCH.
>>
>>
>>So. I go forward with my problem. :)
>>
>>Just for information
>>ERRORBINDUNG failed. I use an aditional parameter on the ERROR. This is by reference to bubble information up and down the line. Eventbinding to such stuff normaly errors out with 11. The eventbinding fails very strange. It get's executed, but the 4th parameter is not passed. PCOUNT() returns 3 instead of 4. I need no help on this.
>>
>>Lutz
>>>Ok if that's what you want then you have a good point.
>>>
>>>But then again - why do we care about the object's state? Is that really going to be all that helpful? If you have known errors that you need to handle then T/C will do that just fine. In fact, I advocate that any OO interface should have top level methods abstract lower level interfaces in such a way that hte caller gets meaningful error information (via return values or a thrown exception with a proper error signature) that either trap all errors with their own error handlers or else let the error bubble.
>>>
>>>The problem with .Error() is that it's all to easy to let an error happen that way and then not be able to be anything useful with it. How do you communicate the error to the caller? If you're several levels down. That was always what I HATED about Error methods. There's no 'standard' way to do this and if you're dealing with code that somebody else wrote you often won't even know.
>>>
>>>These are two very different approaches - internal and external - and both have their advantages and drawbacks.
>>>
>>>+++ Rick ---
>>>
>>>
>>>>Hi Rick,
>>>>
>>>>lets see how we get a nidea into me. :)
>>>>
>>>>how those AERROR return an object reference? IOW how does a top level error trapping get an reference to the object where the error occurs, so that I can log the status of the object? Because of the way the call stack goes the object might even no longer exists if the CATCH fires ...
>>>>
>>>>I still stuck with the idea that encapsulation means that an object should deal with it's errors rather then a non OOP handler far beyond