Hi! Summary: ======== In Zope 2.10 'raise_standardErrorMessage', 'zpublisher_exception_hook' and therefore 'Publish.publish' did always (re-)raise errors after rendering. That made sure 'HTTPResponse.exception' was called and CookieCrumbler was able to hook into 'HTTPResponse._unauthorized'. I'm now trying to figure out how this bug could be fixed: https://bugs.launchpad.net/zope-cmf/+bug/558340 Some details: ============= In Zope 2.10 and earlier the code did (re-)raise errors this way: raise error_type, error_value, traceback 'error_type' is the original error class, 'error_value' the rendered error message. Python creates a new error instance, basically trying to do this: error_instance = error_type(error_value) That doesn't work if the error class constructor requires more than one argument. This was the first change that broke the old behavior: http://svn.zope.org/?view=rev&rev=77459 The comment in Zope2/App/startup.py is interesting because it says "raise the rendered value" while the code actually *returns* it: # Lookup a view for the exception and render it, then # raise the rendered value as the exception value # (basically the same that 'raise_standardErrorMessage' # does. I guess the checkin message for http://svn.zope.org/?view=rev&rev=92767 explains why: "Rather nasty fix to work around Zope 3 exceptions that have more than one positional argument on the constructor." The old machinery doesn't work with ZTK exceptions like zope.publisher.interfaces.NotFound because they take additional arguments and have are more complex __str__ method. There is an inconsistency in revision 92767 ( http://svn.zope.org/Zope/trunk/lib/python/OFS/SimpleItem.py?rev=92767&view=d... ): The checkin message says: "work around Zope 3 exceptions that have *more than one* positional argument". I think that's correct. The comment in SimpleItem.py says something different: # Can we re-raise the exception with a rendered-to-HTML # exception value? To be able to do so, the exception # constructor needs to be able to take more than two # arguments (some Zope exceptions can't). The code follows that comment, so 'can_raise' is sometimes wrong. E.g. can_raise is True for zope.publisher.interfaces.NotFound, but re-raising with the rendered value as only argument doesn't work. Proposal: ========= We could try to fix bugs like the one mentioned above. And we could restore the old behavior for normal Zope 2 exceptions, fixing the CookieCrumbler issue. But the whole thing looks like a big mess. I think we should try to find a way to treat all kinds of errors the same way. I see two possible approaches: 1.) Stop re-raising errors. Always return rendered values and pass them on to the places where the errors are currently catched. 2.) Re-raise the original errors. And store the rendered value somewhere else. Maybe in the response object. What do you think? Any comments are welcome. Cheers, Yuppie