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

[Tim Peters]

[Michael Dunstan]
> My limited understanding is that closing a connection is the only time
> you can expect to see a ConnectionStateError.

That's true in ZODB 3.2.4c1.  ZODB 3.3 also raises ConnectionStateError in
other cases where a requested operation makes no sense due to the current
state of a connection.  For example, trying to load an object from a closed
connection, or even asking a closed connection whether it's read-only.  A
lesson that's been a long time in the learning here is that complicated APIs
can't really rely on users adhering to undocumented restrictions <0.7 wink>.

> Where as you can expect a ConflictError anytime you attempt to access a
> persistent object.

Pretty much so, yes.

> Also worth noting that Zope3 development is (or was?) considering using
> something like RuntimeError as the base for POSError(?) and using the
> pattern:
>
>      try:
>          ...
>      except RuntimeError:
>          raise
>      except ...:
>          ...

Unfortunately, that was based on believing the Python docs when they said
RuntimeError is "not used much anymore".  RuntimeError is actually used in
lots of places, and is even the base class for NotImplementedError.  The
hope was that Zope3 could hijack some unused builtin exception for use as a
base class, but there really aren't any.  Well, as of 2.4, the builtin
OverflowWarning will be unused.  Writing "except OverflowWarning:"
everywhere wouldn't be an improvement, though.  There's some discussion of
this on python-dev now; another problem is that C code also routinely
suppresses "dangerous" exceptions (e.g., hasattr() suppresses all
exceptions, including KeyboardInterrupt, MemoryError, ConflictError, and
SystemExit).