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

[Tim Peters]

[Tim Peters]
>> POSKeyError should be impossible.  Alas, "should be" != "is" across the
>> time I've been fighting this.  Think of "<wink>" as suicide prevention
>> in this context.  I never realized POSKeyError derived from KeyError,
>> and it doesn't seem sane that it does.

[Chris McDonough]>
> Ah ok.  So it probably wouldn't hurt to make it sticky then, I presume?

Sorry, I really don't know -- but I *guess* that would be OK.  I have
more-or-less deep understanding of the pieces of ZODB that have broken on my
watch and so needed bugfixes.  My understanding of the rest is fuzzy to
non-existent.  Same way I learned about BTrees.  Luckily <wink>, they
eventually turned out to be broken in many places (some gross, most
microscopic), so I eventually learned almost everything about them

Digging thru the old UML models for ZODB:

    http://www.zope.org/Documentation/Developer/Models/ZODB

I see that the storage interface says of load():

    A KeyError exception is raised if there is not a record for the
    given oid and version.

I can deduce that this is *why* POSKeyError derives from KeyError, but have
no way to guess whether anything relies on that.  A few ZODB tests probably
do.  But as you said, it's dreadful that app code can end up swallowing a
POSKeyError in general code that doesn't care about, e.g., vanilla dict
lookups failing.  POSKeyError is serious.

OTOH, what happens if you suppress one?  It means you tried to load a thing
that couldn't be gotten.  If your app tries to make any use of that thing,
it will get POSKeyError again, because the load didn't succeed, and never
will.  So in that sense it's already "kind of" sticky.  It won't stop the
current transaction from committing if it's suppressed, but if an app really
needs a thing that isn't in the database, it will get POSKeyError over and
over again.  Retrying the transaction can't cure that, either.

If POSKeyErrors were common, I could conceive of code resorting to:

    try:
        obj = thing1
    except POSKeyError:
        obj = thing2

in desperation, and then it would be bad if the intentionally suppressed
POSKeyError prevented the transaction from succeeding.  But I strongly doubt
that there is code like that, and POSKeyError really is supposed to be
impossible (and despite that it's apparently common in 2.7.2 ...).