[dev] [commits] Horde branch develop updated. 90cc999e6173bc827b2387090249ec7e8f3e48eb

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> 0c01370 [mms] Import API call now throws an ObjectExists  
>>>> exception when a duplicate is found.
>>>
>>> We have similiar exceptions in the other groupware application  
>>> APIs, so this go into the Horde_Exception package. If for some  
>>> reason this isn't possible, this exception should extend  
>>> Turba_Exception instead.
>>
>> I don't agree with the former: ObjectExists is pretty generic (does  
>> it refer to a Turba_Object?  Or maybe a Turba_Widget_Foo_Object?),  
>> so it necessarily needs to be defined in each application depending  
>> on the data a particular application is dealing with.
>
> But how is this different from, say, Horde_Exception_NotFound, which  
> is the logical counterpart exception?

An "object" is way too broad, in my opinion. and it doesn't really  
provide any context of *what* object doesn't exist.  i.e. Nobody would  
ever catch an exception at the Horde_Exception_ObjectExists level.

When using the Turba import call, I only care if a Turba Object  
exists.  If some other object exists that causes an exception, it can  
be caught at the Horde_Exception level - there's no difference in this  
case between Horde_Exception and Horde_Exception_ObjectExists where I  
don't know/care *which* object doesn't exist.

Import is kind of a special case since there can be instances where  
the calling code wants to ignore the fact that the item already exists  
(if import is called automatically) vs. informing the user if the  
contact already exists (if import is called because of user input).  A  
generic ObjectExists exception doesn't add anything here.

If you want to add this, I won't protest.  I just personally don't see  
the need for it.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]