Lets take this back to the list Ive trimmed the cc list to people I think
might be interested.
http://collector.zope.org/Zope/869
I am not in line with your principle the error report is
part of [the output of] the first transaction.
The error report tells you what went wrong. You can
I am not in line with your principle the error report is
part of [the output of] the first transaction.
The error report tells you what went wrong. You can only generate an accurate
report if you see the objects in the error state. Zope is saying to your
application: your transaction is
The view has access to the original request that ended in the error. The
view is looked-up and rendered in a new transaction.
A new transaction means that *arbitrary* changes may have occurred to the
application state in between:
1. the transaction that raise the error, and
2. the transaction
Bjorn Stabell wrote:
Hi Zope gurus,
After upgrading to Zope 2.6.1 on Linux, when submitting forms, we
sometimes get this error:
Site Error
...
exceptions.IOError
...
Traceback:
Module ZPublisher.Publish, line 150, in publish_module
Module ZPublisher.Publish,
Toby Dickenson wrote at 2003-4-4 10:24 +0100:
...
Currently Zope doesnt allow the error report to do something persistently, and
the use case for this is not obvious to me. Can you explain the use case? I
am hoping that there may be a better solution that avoids the problems I
raised.
Toby Dickenson wrote at 2003-4-4 15:54 +0100:
Access to the doomed state at the end of the transaction is what zope 2 gives
us today.
This is not the case.
Zope 2 as it is now performs error handling in a separate
transaction.
However, the error handling transaction is not
