[Zope-dev] Re: exception hiding in _delObject

[Dieter Maurer]

Tres Seaver wrote at 2004-11-9 13:28 -0500:
>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
> ...
>> 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.

And in addition, it can leave the ZODB in an inconsistent state.
As you know, "manage_beforeDelete" is a recursive function.
When the exception occurs, it probably had run for part of the
descendants but not for others.
Almost surely, this will give you further unexpected problems
in the future.

>> 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 ?

I would be even more strict: do not catch the exception at all.

ZODB inconsistencies are as bad when caused by "Manager" intervention
as when caused by "normal" users.

>-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.

-1 on deleting the object and leaving inconsistent ZODB state
behind. Better fix the application code and then try again to
delete the object.

-- 
Dieter