Hi Rick,

I see the problems with the event but i see the problems with the TRY CATCH too. On this I stay with the message fromn dragan.

#1
It's quiet a bloat to add TRY CATCH to each and every method / event / procedure / function. This is simply not maintainable

#2
There are limitations to TRY CATCH. See "Structural Error Handling" in VFPs Help
This is in special the use of LOOP and RETURN inside a TRY block. If something is working level deep with LOOP - this seems to bee a bug. We have some luck next version will not break behaviour. :)

#3
This makes it clear that TRY CATCH is the way to a errorhandling scoped localy rather then to generic one. IOW it deals with "expected errors"

#4
Expected errors are much better to deal with (and even to notice the error trapping) then with ON ERROR or events

#5
For what I know an outer TRY CATCH will not return the location (object, class/ classlib) of the error. But this is essential to figure out the strange errors.

#6
The chances to set up a new framework wth VFP are very close to 0 :)

#6
If I do my stuff with a outer TRY CATCH and some third party product will use ON ERROR / event I'm in trouble.

So to me #5 is the stop for it.
Customer does not pay enough for a huge testing (.. for each patch). It's much cheaper in my scenario to run in the error (This is, low tens in a year) and have it good documented. I get around a 100k of error description of a single error. Mostly the inspection of this will put me into the right direction. But to know classes and librarys is essential to this.

Even on testing a error traping that simply would put my several layers away from the error. It feels like error handling in the days of my Sinclair ZX Spectrum.
I prefer to let it run into the error and stop there, set breakpoint and rerun, to set a breakpoint close to a "Guess" and endless singlestep forward.

I stand to my point that both have there use
-ON ERROR / event for the unexpected, general handler (RETURN TO is not that tricky to stop the whole thing)
-TRY CATCH for the expected

Each of them are clumsy the other way.

For my problem - a generic factory for object creating - I need to akwardly move around. But this is the only place. In this it violates the rules of encapsualtion anyway. This is the henn or the egg since an object needs to be instantiated from outside.

Lutz

>
>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