[Zope-dev] Re: "hasattr" geddon

[Shane Hathaway]

On Saturday 10 July 2004 11:41 am, Tim Peters wrote:
> [Shane Hathaway]
> > when the real problem is ZODB?  ZODB
> > should *not* be sensitive to the way the application handles
> > ConflictErrors. When a ConflictError (or ReadConflictError) occurs, the
> > transaction should fall into an "uncommitable" state.  From this state,
> > you can only abort the transaction; any attempts to write an object or
> > commit cause another ConflictError.
>
> AFAIK, that is the way the current releases of ZODB work.  I'm not
> sure what "write an object" means there, though.  I think I know what
> "commit" means.  The logic in Connection.commit() raises
> ReadConflictError upon an attempt to commit an object that previously
> suffered a conflict during the transaction.  How does that differ from
> what you want?

Here is what often happens in Zope:

def setFoo(self, value):
  try:
    self.foo = value
  except:
    LOG("Oops", ERROR, "Some error happened", error=sys.exc_info())
  self.change_count += 1
  self.get_indexes().update(self)

Some piece of code has a legitimate reason to catch but log all exceptions.  
Some other piece of code updates indexes.  The database has now committed a 
partial transaction.  Even worse, this can happen within the indexes, making 
the indexes inconsistent with themselves.  Once a conflict error has occurred 
on any object, the rest of the transaction is on shaky grounds.

> Guido doesn't agree; hoping that Python will change here is probably
> futile (Guido has said several times that hasattr() should never raise
> an exception, and that matches how it's always been documented and
> implemented).

That's unfortunate.  Now I'm inclined to never use hasattr again.  Can we 
petition for "hasattr2" then? :-)

Shane