>Bottom line to all of this is you should not mix TRY/CATCH with Error methods in your own objects. Any called objects that have their own error handling with Error methods or TRY/CATCH will work correctly but your own code should avoid mixing the two.
>
>It can get very confusing to debug when both are present.
>
>I went through this with Web Connection which originally relied on Error methods and then switched over to TRY/CATCH. Some other objects would have Error methods and so the error wouldn't bubble and just get eaten.
>
>Personally I don't use Error events any more because they have always been a pain - but they were the only thing we had to internalizing errors in objects. TRY/CATCH is just much cleaner as you can deterministically cover blocks of code.
>
>In your ADDOBJECT/NEWOBJECT code you can probably create factory methods that are wrapped with TRY/CATCH blocks to deal with that scenario.
>
>+++ Rick ---
>
>>Hi all,
>>
>>I have a problem wit TRY CATCH errorhandling
>>Example
>>

>>lomu = NEWOBJECT('mu')
>>
>>add_p(_SCREEN)
>>
>>lomu.add_x
>>
>>
>>DEFINE CLASS mu AS CONTAINER
>> PROCEDURE ERROR
>>  LPARAMETERS;
>>   tnError,;
>>   tcMethod,;
>>   tnLine,;
>>   tvReturn
>>
>>  ?'Error event'
>> ENDPROC &&mu.error
>>
>> PROCEDURE add_x
>>  add_p(THIS)
>> ENDPROC &&mu.add_x
>>ENDDEFINE &&mu as session
>>
>>
>>PROCEDURE add_p
>> LPARAMETERS lomu
>> TRY
>>   ?lomu.NAME
>>   lomu.ADDOBJECT('mux','xxr')
>>
>>   ?'not catchedd'
>>
>>  CATCH TO loException
>>   ?'catchedd'
>>  FINALLY
>>*
>> ENDTRY
>>ENDPROC &&addp
>>

>>
>>As you can see the call for the object will not be catched by TRY CATCH
>>
>>if there is no ERROR event then it is catched
>>
>>Any idea how catch the error? This is a example for my factory and it fails to catch the problems ...
>>
>>Thanks
>>
>>Lutz

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