Philipp von Weitershausen wrote at 2007-3-28 08:16 +0200:
>What makes you think you can make that assumption? This is Zope 2 all
>over again, where things just have to be there. That won't help
>making things more flexible.
Hiding exceptions (or avoiding them at all costs) might be seen as
more flexible -- but this approach caused several quality problems in
>> We have this situation here: there should be (and is) a unique
>> id tool but the local registrations have not been performed.
>Nope, we're just not operating in a place where we can get to the
>tool. It's standard acquisition semantics.
With standard acquisition semantics, you get an AttributeError
when the object is not there.
You propose something similar (okay, a bit less drastic) to
silently ignoring the "AttributeError".
I argue that (in general, there are exceptions) we should get the exception.
>> An exception is better than silently omit the update of the existing
>> unique id tool.
>> You could argue that the local id tool does not need to be updated
>> as the complete site (including the tool) gets deleted.
>> But would the effect be different, if I used:
>> Or in other words, is attribute lookup entailed in traversal?
>> If it is not (which I assume), then your "defensive programming"
>> would hide inconsistencies in the unique id tool -- similar
>> to a "defensive try: .... except: pass".
>What kind of inconsistencies? We're deleting the thing anyway, what's
>the point to update it?
If you carefully look at the example, it no longer deletes "plone_side"
(and its "unique id tool") but something below "plone_side".
Therefore, consistency of the "unique_id_tool" may be an issue (it is
not deleted and would know about an object with no longer exists).
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests