#1 is generally not an issue - you handle that with Composition. In Web Connection I have a TRY/CATCH handler at the top level method that handles all errors in Web Connection processing that aren't internally handled anywhere below. It scales fine. In fact, FoxPro is one of the few languages that has this type of error event trapping at the object level - just about every other language uses TRY/CATCH like as the main error handling mechanism plus possibly an application catch all handler. The TRY/CATCH pattern is widely used and is known to work and scale just fine.
#2 Yeah the fact that FoxPro doesn't support exit points from exceptions INSIDE THE IMMEDIATE CATCH block can be annoying but is pretty minor. Easily fixed by setting a flag and then handling the occasional exit operation based on that flag or other value. Note that code lower in the call stack CAN RETURN just fine.
RETURN TO MASTER | TO < method > is the one thing that sucks with all VFP error solutions unfortunately including T/C and Error methods. I struggled with this one for a long time prior to T/C support.
#5 TRY/CATCH doesn't directly return nested error info, but AERRORS() does. You can most definitely get nested error info. Like I said I use this inside of Web Connection's main processing loop and I get error info all the way down the call stack to report and log errors. You lose nothing that you could do before.
#6 You will be in trouble with that no matter what because ON ERROR overrides all other error handlers except in local scope. T/C will be the immediate t/c block, for .Error() it'll be the current object. No huge difference.
Your main issue seems to be that you're worried about not capturing errors in the call stack, but you can do that with T/C. What's terrible is mixing both .Error() and T/C handling together because you can get some really confusing and hard to track behavior that way.
Oh, and the VFP docs are wrong in a few places for some of the more complex scenarios they describe. I can't remember all the details now, it's been a while since I looked at this but I remember experimenting with a lot of these combinations to see what would work. I think the best reference there is out there was a session and white paper from Mike Helland a long while back...
+++ Rick ---
>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
