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

[Tim Peters]

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

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