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

[Florent Guillaume]

In article <20040907211216.4AD293B8038 at smtp.zope.com> you write:
> [Florent Guillaume]
>  I guess ConnectionStateError is now also part of the exceptions that
> > should not be caught by a bare except:. Do you think we should change the
> > few
> >     except ConflictError: raise
> > that we added in Zope trunk into a more general
> >     except POSError: raise
> > ?
> 
> I don't know.  It requires that someone who understands what that code is
> trying to accomplish, in context, think about it.  By my count, there are 22
> exception classes rooted at POSError now.  So if you change ConflictError to
> POSError, you're going to be reraising a whole bunch of exceptions that are
> currently suppressed (or something -- those snippets doen't say enough to be
> sure what happens in context).  For example, is it intended that Zope not
> re-raise VersionLockError now, or UndoError, or MountedStorageError?  I
> don't know, and "the answer" for each may differ at each site where they're
> currently being suppressed.  Catching POSError will catch all of them.

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.

Florent


> 
> If you suppress ConnectionStateError, the state of the connection remains
> unchanged, although that's (so far) an undocumented implementation detail,
> not (yet) a promise.  So, e.g., if you keep suppressing ConnectionStateError
> in a loop that's trying to close the connection, that loop will never end
> (the attempt to close will continue raising ConnectionStateError).  OTOH, if
> you suppress ConnectionStateError and then abort() or commit() the
> transaction, it's (currently) the same as if you hadn't suppressed the
> ConnectionStateError -- no harm done.  So there's no answer to the question
> short of case-by-case analysis performed by people who understand the intent
> of each place it was decided not to reraise non-ConflictError exceptions
> (optimistically assuming that was deliberate intent ...).
> 
> _______________________________________________
> For more information about ZODB, see the ZODB Wiki:
> http://www.zope.org/Wikis/ZODB/
> 
> ZODB-Dev mailing list  -  ZODB-Dev at zope.org
> http://mail.zope.org/mailman/listinfo/zodb-dev
> 


-- 
Florent Guillaume, Nuxeo (Paris, France)
+33 1 40 33 71 59  http://nuxeo.com  mailto:fg at nuxeo.com