Hi Rick,

lets see how we get a nidea into me. :)

how those AERROR return an object reference? IOW how does a top level error trapping get an reference to the object where the error occurs, so that I can log the status of the object? Because of the way the call stack goes the object might even no longer exists if the CATCH fires ...

I still stuck with the idea that encapsulation means that an object should deal with it's errors rather then a non OOP handler far beyond



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