>When an error occurs on an object, the object's error method has priority over any try/catch. If the object doesn’t have an error method, but it is a member of a class that does, then that error method will be used.
>
>The error method of an object (or if it’s an object member, it’s containing class) takes precedence over try/catch because classes are meant to be encapsulated. If a class designer were to write code with its own error method to achieve a particular behavior, a user of that class should not be able to break the class behavior simply by using a TRY/CATCH in the client code.
>
>In the sample code, the collection is a member object of a class that has an error method. The error occurs on the collection object, the collection belongs to the "HasACollection" class, and so the "HasACollection" error method is fired.
>
>One way to see this is to use a global for the collction: try addng this code to the "HasACollection" class
>
>

>	PROCEDURE init
>		PUBLIC oparams
>		oparams=NEWOBJECT("collection")
>

>
>And in the TRY/CATCH, do this:
>

>		TRY
>			oItem=oparams.item(cname)
>			oItem.value=uvalue
>*!*				oItem=This.params.Item(cName)
>*!*				oItem.Value=uValue
>
>

>
>Now the error method doesn’t fire because the collection does not belong to a class with an error method.

Thanks for clearing this, Calvin. If the help file was editable, I'd just paste what you wrote here into the help for the Try/Catch command.