[Zope-dev] Re: [ZCM] [ZC] 869/ 5 Comment "Broken transaction handling in case of exceptions"

[Steve Alexander]

>>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 doomed. tell me why."

I'm interested in this for Zope 3.

Currently in Zope 3, you can register a view to give a custom 
presentation of an error that reaches the publisher. The view can also 
do persistent work if it needs to. An example of this is recording 
against a User record that a login failed for that User.

The view has access to the original request that ended in the error. The 
view is looked-up and rendered in a new transaction. The new transaction 
is committed if there were no errors raised, otherwise it is aborted.

Do you think this error handling system is insufficient for your needs?

Can you give an example of the kind of situation where you'd need access 
to objects in a doomed transaction in their doomed state, in order to 
make an error report?


I'm interested in improving the error handling system in Zope 3, so your 
use-case will be very useful.

--
Steve Alexander