Le Tuesday 13 May 2008 20:02:42 Dieter Maurer, vous avez écrit : > Someone convinced us that error handling should (of course) > see the state the error happened and not a new clean state -- in > order to be able to report about the errorneous state....
Then, in my opinion, it should not be executed "inside" what failed, but in a clean environment with a "pointer" (in non-technical meaning) to the failed transaction. Or there must be some special directives about what can or cannot happen in an error handler (but I guess it's just too hard to make sure nothing joins a transaction, for example fetching a page template from ZODB to render the error will join the transaction). > Another reason was also: should your error template need to run > in a fresh transaction, then just abort the old one. How ? IIRC it's a bad coding practice to interact with transaction mechanism from what's considered as "inside" a transaction (ZPublisher being the borderline). > If the transaction were aborted before error handling, then > an error template with different requirements does not have a chance.... Right. Maybe 2 cases should be handled differently: - exception happened when processing transaction: do not abort immediately - exception happened in transaction handling (hopefully only in "commit"): abort to offer error handling a "usable" environment Anyway, I opened a bug in the bugtracker about this problem, because it's a separate issue from the TM.py problem: https://bugs.launchpad.net/bugs/229863 -- Vincent Pelletier _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
