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