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

[Chris McDonough]

On Tue, 2004-09-14 at 15:01, Dieter Maurer wrote:
> Chris McDonough wrote at 2004-9-14 00:38 -0400:
> > ...
> >Despite the special behavior of POSKeyError (a particular object can't
> >be loaded), it seems that catching one inappropriately can produce the
> >same sort of app-level inconsistencies as any other kind of error.
> 
> I have code that expects "POSKeyError"s because it looks at
> old ZODB state (state as it was at a given time; because some
> objects states at that time might have been packed away, "POSKeyError"s
> are inevitable). Of course, it catches "POSKeyError".

I'm sure I just lack imagination, but I'm not sure I understand.  How
could objects that apparently had a nonzero reference count have been
packed away?  Or was this caused by the recently fixed 0-day pack bug? 
Or is this code part of your MVCC-using-undo implementation?

> I would not be happy when the occurence of a "POSKeyError" would
> make it impossible to commit the transaction. Of course,
> the connection that looks at the state in the past will not allow
> old state to be modified but other connections may look
> at current states and may want to change them.
> 
> *ALL* exceptions can potentially affect app-level invariants.

Yes, that was noted in my first "rule" in an earlier message in this
thread.

> Nevertheless, there are for (almost) all types of exceptions use cases
> to catch them -- provided you know what you do.
> 
> Use this "sticky" mechanism with care only...

Right... Since you've found reasons to catch it in the past, POSKeyError
shouldn't be made sticky then.  Your example made me think of other
kinds code that could want to commit even in the face of POSKeyErrors
(although they are pretty tortured examples), so I can understand why
not allowing a commit would be a problem.

I just wish it didn't subclass KeyError.  Maybe instead of going on a
sticky jihad I should make a ZODB branch that had a POSKeyError that
didn't subclass KeyError.  Would it be reasonable to make this change
for 3.3 or should I just forget it?

- C