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

[Tim Peters]

[Chris McDonough]
...
> c) There are exceptions to "b" for cases where it's improbable
>    or impossible to predict the codepath due to ZODB implementation
>    artifacts (eg. ReadConflictError). In these cases it is reasonable
>    to expect ZODB to "help" by rendering a transaction uncommittable,
>    preventing the developer from needing to put a try: except:
>    DeathByChris block around every statement that does attribute access
>    on persistent objects.
>
>    Relatedly, as a nicety, wherever a "fatal" exception is
>    raised (one that is not supposed to be caught by anything except
>    perhaps something that catches it explicitly, and one that is only
>    meant to be raise by the ZODB framework) and when it's possible to
>    do in a sane way, the associated transaction should probably be
>    rendered uncommittable by the ZODB framework.  (POSKeyError,
>    VersionLockError, etc)

A practical problem is that "the framework" has no choke point for errors.
VersionLockError is raised by a variety of storage implementations that
happen to support versions; likewise for various flavors of undo errors;
POSKeyError is raised by one specific storage implementation;
ReadConflictError is raised by a jar; ..., and storages in particular have
no idea which Transaction object may be in current use (get_transaction()
only reveals what the current thread transaction manager believes, but the
user may not be using that transaction manager).  So there's a lot of code
that would need to be fiddled to make these all "sticky", including external
implementations of storages (and jars, if there are any externally defined
jars).

If we had a handle on "the current transaction", and a way to doom
transactions, then instantiating one of these exception objects could manage
to stop commit; but that's three steps away from current reality.

> d)  A corollary: it would be nice if some exceptions couldn't be
>     caught except explicitly.  It's nice in Zope's case because it
>     removes a bit of data integrity maintenance responsibility from
>     both the developer who uses Zope and from the developers who create
>     ZODB and into a centralized top-level exception handler within
>     the publisher, which can handle these sorts of things in a
>     well-defined way.

That would be nice, yes.

> e)  A final corollary: bare excepts should be prevented in app code
>     as well as things like hasattr which has same effect.

It's always dangerous.

...

>> Armin Rigo has a speculative patch pending that tries to get "dangerous"
>> exceptions raised *even if* PyErr_Clear() gets done at the C level.

> This seems like a sane thing as long as you can define what "dangerous"
> is.

Presumably we'd split Python's exception hierarchy, and define a base class
for dangerous exceptions.  For example, MemoryError definitely belongs in
that class.  In a little-known disaster mode now, if you have code that ends
up triggering MemoryError during dict lookup, the C-level dict lookup code
can end up suppressing the MemoryError and turning it into a KeyError by
accident.  So code can go crazy, failing to retrieve something it *knows* is
in a dict.  That case was actually the trigger for Armin's patch.  Indeed,
if a dict lookup triggers a ReadConflictError or POSKeyError (or anything
else), the same thing can happen; PyDict_GetItem() suppresses all exceptions
now.