>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