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
Now the error method doesn’t fire because the collection does not belong to a class with an error method.
