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
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
> rai
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, lin
> 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
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 doo
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 ca
