While agreeing with most of the points wholeheartedly and with a sufficient number of whites in my beard to add gravity to the subject (though I don't really know how many of them were caused by VFP's error handling in the past... but surely many were), I''d just add one point here.

A catch-all handler, even if it's a try/catch, is only your last line of defense. If the error wasn't caught within the method where it happened, the code jumps all the way up the call stack to the last known catch statement, at which point calling aStack() will not know only the stack to that point, not to the point where error happened. So there's a lot of code to be written, as try/catch has to be rather local to be really useful. Calling code to unknown depths from within a try/catch is fine while it doesn't error out, but when it does, it gets really hard to pinpoint the location. You know that it happened on .click() line 10, but at which object, and whether it's local or some parent class code (calls via dodefault() add to the confusion) remains unknown.

The upside of old error handlers was that they were called code (with a "on..." getting on the stack before it), so at least aStack() would give you useful info... with everything else being pretty much the downside.

>>A try catch will catch anything unless the stuff to catch runs in the context of an object not in focus of the calling object / procedure.
>>IOW One can not catch objects code from outside.
>
>Not quite. If I would start from scratch, my suggestion would be to NEVER use an Error() method handler ever. Always use TRY CATCH instead. It's much easier to predict error behavior that way and you CAN definitely catch errors from inside of an object that is nested inside of a TRY/CATCH as long as there is no .Error() method in the call chain.
>
>The problem is that .Error() breaks the TRY/CATCH call chain and that can cause errors to effectively get eaten - you never know about them if the Error handler decides not to pass the errors forward. And that's why I think .Error() methods typically are a bad idea. The only reason to use them was that we had no alternative short of ON ERROR which is even worse (same concept though - based on events, non-deterministic) :-)
>
>TRY/CATCH let's you create a catch all handler at the top of your application - something you can't do with an .Error() handler too. The problem with .Error() is that it's scoped to the object you're dealing with itself. TRY/CATCH allows you to externalize the error and deterministically capture it. The Error() method is an event so you get called and all that you can effectively do on that error is set a property and call more code, but it's really hard to build a framework around that because you constantly have to check for errors. Outside code that needs to act on errors have a really hard time .Error() method handlers.
>
>I dealt with this cycle in Web Connection and one of hte biggest changes in Web Connection 5.x when it upgraded from 4.x was removinig the old .Error() method based approach with a determinisitic TRY/CATCH approach. The latter is much more reliable and consistent, but it did cause some pain because most existing apps had .Error() handlers and if those didn't get removed/replaced with other error handling errors would just not fire - resulting in empty responses typically.
>
>THere are ways to make .Error() methods work as you point out with event binding and a few other tricks, but it's a hack at best. This was always something that I really hated in VFP until TRY/CATCH was introduced. Deterministic error handling is a key feature for any language and especially for frameworks that need to deal with generic code.
>
>+++ Rick ---
>
>>
>>Normaly this is no problem, because error trapping should be encapsulated in the object anyway. This the normal way of doing.
>>
>>I have a handler for the "unexpected" stuff using the ERROR events for decades. I like it more then the ON ERROR because I get better information about the objects and classes where the error occurs.
>>
>>The "expected" stuff is done by TRY CATCH because this is more clear in the logic then something hidden in some error handler class / event.
>>
>>But this is special, because this is the factory to instantiate stuff. This is outside of any other class by design. It needs to deal with the problems but they occur in the container. So I'm a bit in a loop.
>>
>>I start considering the EVENTBIND to the ERROR event to catch the error in my factory class ...
>>
>>Lutz