>>Oh,
>>
>>I came out very clear now. :)
>>
>>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.
>>
>>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
>
>If you can stay away from Error event (because are using Try/Catch), will be better. I've came with the errors Rick described, and having the Error event traping the errors that you think are trapped by a Try/Catch is a really pain, and not easy to figure out.
>
>I think that the error traping should be something easy to maintain, not hidden like the Error event. Another problem with Error event is that it is not scalable, with a Try/Catch on the same code, it is much more easy to maintain and you never forget it, because it is right there, in the code in the same window like the other code.
>
>In legacy code we have, I've taked out almost all the Error event code, because we use Try/Catch for some year now, and the mix was too difficult to debug and unpredictable. Now it is much more easy to take the management path of the error through the code, and TRHOWing the error is equally easy.
>
>One tip on Try/Catch you may know:
>When trapping an error with "CATCH loEx", you can add extra info in the object like this:
>loEx.UserValue = "extra info"
>
>That way, when you THROW, the exception object carry this info with it (A warn: "THROW", not "THROW loEx"!), and every intermediate CATCH can add extra info if needed, so you can get all the info to debug and fix the error.
>
>
>Fernando.-

Hm. Thank you for your suggestion.
I do not see where you catch / intercept unexpected erros? I mean O.k. I can remove all the events and put an outside TRY CATCH at the event loop. But then I remove every chance to debug a failure, because I can not retry / ignore / return (in debug mode, naturaly)

Also debugging inside a TRY CATCH is a pain.

I've never gone into deep with TRY CATCH because my error handler runs pretty well. I saw, as TRY CATCH was new, that there are problems with objects and outer TRY CATCH, but it never was needed. I removed some handlers that where run with the event by TRY CATCH for convenience and anything was fine.

So I use the event / ON ERROR for the unexpected and TRY CATCH for the expected errors.

Need to think about it...