Philipp von Weitershausen wrote at 2007-3-26 14:24 -0600:
> ...
>> I would not find is a good approach, if exceptions were silently
>> suppressed.
>Let's look at this closer:
>- There's probably an event subscriber for IObjectBeforeDeleteEvent on 
>all Plone or CMF objects that makes sure that the deleted item is also 
>purged from the unique ID tool. So far so good.
>- If that subscriber uses getUtility() calls and doesn't catch a 
>ComponentLookupError, it bluntly assumes that all such content objects 
>must live in an environment that has a unique ID utility. That's asking 
>for a lot (it's almost as bad as simply wanting to be able to acquire 
>portal_uuid or whatever it's called).
>- To make reuse easier, the suggested pattern is to check if such a 
>utility can be found and then do the unregistering (or even registering 
>when the object is added). If the utility can't be found, then that's 
>too bad but shouldn't impact the actual use of the content type. After 
>all, it's just a dumb content type.
>This isn't about silently suppressing exceptions, it's defensive 
>programming to increase flexibility.

As so often, we have completely different views on how things should be:

  When I have an "IObjectBeforeDeleteEvent" subscriber which
  should update the unique ID tool, then it can assume that
  there is indeed a unique ID tool. And if the assumption is
  wrong, an exception should result.

We have this situation here: there should be (and is) a unique
id tool but the local registrations have not been performed.
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".

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to