> 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 that reports it In principal it is posssible to delete the database state and import a whole new application between these two points. The object containing the originally published method might no longer exist. I guess that might not matter if your error page just says "sorry an internal error has occurred" - if you want your users to be shielded from the details of any problem. I have some applications at the other extreme, where the users are all capable of debugging any problem and I want the error page to be a "core dump" of application state. > 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? Access to the doomed state at the end of the transaction is what zope 2 gives us today. Access to the objects restored to their state as they were at the beginning of the failing transaction would be ok too (maybe even better) but zodb cant do that today. Either of these two are necessary for easily providing an error report that displays application state explaining why the error occurred. Under the Zope 3 model I think I would need to take a non-persistent copy of the application state in an exception handler towards the end of the first transaction. The second, error-reporting transaction would dump the copy, rather than dump what it sees to be the current world state. It is important that the objects passed from one transaction to the next are non-persistent, otherwise bad zodb-level things can happen. Does Zope 3 guard against this? -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )