In article <[EMAIL PROTECTED]> you write:
> Florent Guillaume wrote:
> > In _delObject and manage_beforeDelete there's a try/except that catches
> > nearly everything (except BeforeDeleteException and the infamous
> > ConflictError). It then proceeds to log a message, but continues:
> > try:
> > object.manage_beforeDelete(object, self)
> > except BeforeDeleteException, ob:
> > raise
> > except ConflictError: # Added for CPS
> > raise
> > except:
> > LOG('Zope',ERROR,'manage_beforeDelete() threw',
> > error=sys.exc_info())
> > pass
> > The rationale is, I guess, that when you delete an object you really
> > want it gone.
> Yep; especially as the broken object may be screwing up something
> *important* to the site.
> > This is IMO very harmful because it hides any bug in the catalog or the
> > indexes (especially during unit tests where LOG is ignored). I've been
> > (again) bitten by it.
> > I'd like to condition the pass to the fact that the current user is
> > Manager. Otherwise I'd like it to fail (and reraise). So a Manager will
> > still be able to delete objects when there's a bug, but not others.
> > Comments ?
> -1. Buggy application code blocking deletes makes for nightmare "throw
> away your Data.fs" error scenarios. I am +0 on it if you can arrange
> for the new behavior to happen only when Zope is running in debug mode.
Ok I'll do the change so that the exception is reraised only in debug
mode AND if the user is not Manager (so that a Manager can still fix the
Opinions on whether it can go on the 2.7 branch too ?
Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -