[ZCM] [ZC] 264/ 3 Resolve "AttributeError: 'None' object has no attribute 'load'

[Collector: Zope Bugs, Features, and Patches ...]

"
X-Recipients-debug: ['htrd', 'jeremy', 'klm', 'Brian', 'chrism', 'Caseman', ('_Resolved_ recipient', 'zope-collector-monitor at zope.org')]

Issue #264 Update (Resolve) "AttributeError: 'None' object has no attribute 'load'



"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/264

==============================================================
= Resolve - Entry #3 by jeremy on Jan 17, 2004 4:43 pm

 Status: Pending => Resolved

Fixed long ago, no?

________________________________________
= Comment - Entry #2 by d.maurer on Mar 27, 2003 2:16 am

I do not think, that error handling can see a closed connection.
The connection is close when the request object is deleted.
But, this happens only after error handling.

However, there is an essential bug with Zope's transaction
handling we have already discussed on zope-dev.
I now understand it better and will file a collector
report.
________________________________________
= Request - Entry #1 by htrd on Mar 5, 2002 10:04 am


Uploaded:  "setstate.diff"
 - http://collector.zope.org/Zope/264/setstate.diff/view
2002-03-05T14:12:53 ERROR(200) ZODB Couldn't load state for '\x00\x00\x00\x00\x00\x00\x17-'
Traceback (innermost last):
  File /home/tdickenson/projects/Zope2/lib/python/ZODB/Connection.py, line 469, in setstate
AttributeError: 'None' object has no attribute 'load'


The zope lists have seen numerous reports of tracebacks like the one below. The concensus was they were harmless, but (as far as I know) noone has properly diagnosed what was going on.

This traceback is generated when ZODB is asked to load the state of an object outside a transaction, when the connection is closed. This can be triggered by a standard_error_message object, or even the standard error page, because it is rendered *after* aborting the transaction.

Even worse, I think it is possible for the persistent object to be connected to a different transaction before the error message is rendered.

Im not sure of the right fix. In ZPublisher/publish.py publish function, should the call to transaction_manager.abort() occur *after* the err_hook stuff?

This patch just makes the error message nicer.







==============================================================