[ZODB-Dev] RE: [Zope-Annce] ZODB 3.2.4 release candidate 1released

[Tim Peters]

[Florent Guillaume]
> Actually the ones I'm thinking about have been added to code that
> originally did:
>     try:
>         ...stuff...
>     except:
>         LOG('an error happened: %s' % sys.exc_info())
>         # continue anyway as we "shouldn't fail"
>         # or we "want to return a default value if we fail"
>     ...rest...
>
> This happened for instance in manage_beforeDelete, _delObject or even
> restrictedTraverse.
>
> This was changed to:
>     try:
>         ...stuff...
>     except ConflictError:
>         raise
>     except:
>         LOG('an error happened: %s' % sys.exc_info())
>         # continue anyway as we "shouldn't fail"
>         # or we "want to return a default value if we fail"
>     ...rest...
>
> To make sure we didn't inadvertently catch something that could make the
> database inconsistent.

I don't know of a scenario in current ZODB wherein catching something can
make a database inconsistent.  I understand there are persistent rumors that
it can happen, but requests for a specific case have gone unanswered.  So I
suspect something else is at work, and "catching exceptions" is a convenient
scapegoat in the absence of understanding.  Perhaps these are just stale
rumors, left over from earlier versions of ZODB.

There's generally no *point* to continuing a transaction once it has
experienced a ConflictError -- current ZODB intends never to let a
transaction commit if it experienced a ReadConflictError in its lifetime.
So as soon as you see one, you may as well give on the transaction ASAP, and
retry it.  But there's still no general way to know exactly what "ASAP"
*means* from code snippets -- it depends on the full context, and may mean
different things in different contexts.