Dennis Allison wrote at 2007-9-20 09:37 -0700: > ... >standard_error_message should be acquired. It should be possible for >there to be multiple copies with the particular one to be used selected by >acquisition. This does not appear to be the case for some errors in my >configuration, but I am not sure why.
You are right -- and I can explain why. >There appears to be nothing in the Zope 2.9 zope.conf file that has to do >with catching error messages. Is there some configuration that is >missing to enable full custom error messages. > >Looking at the code: > >ZPublisher/HTTPResponse.py seems to have a complete set of error >responses hard-wired with outputs that mimic those of the default >standard_error_message. > >OFS/SimpleItem.py includes a method called raise_standardErrorMessage >which first acquires and then publishes the standard_error_message. > >Zope2/App/startup.py has a method, zpublisher_exception_hook which >uses raise_standardErrorMessage and is referenced in ZPublisher/Publish.py >where it is used to set error_hook, but error_hook does not appear to be >used. > >It would be helpful to me if someone who understands how this particular >code works could provide some hints as to what's needed to fully customize >the error message responses. We start with ZPublisher. It is this component that catches the exception and activate error handling. ZPublisher was designed as a general publication component -- to be used not only for "Zope". Therefore, it has neither error handling nor transaction handling nor a few other things hard coded. Instead, it gets a module name and determines the relevant pieces by a call to "ZPublisher.Publish.get_module_info(module_name)". When "ZPublisher" is used for Zope, then "module_name" is "Zope2". "Zope2" defines "Zope2.zpublisher_exception_hook" as its exception hook (which does the error handling). The true "zpublisher_exception_hook" is defined (as you found out) in "Zope2.App.startup" and copied to "Zope2" by the "_startup" call. When ZPublisher catches an exception, it calls the error hook with "parents[0]" (the last or second to last object traversed to), the request and the error information. "zpublisher_exception_hook" then looks in the acquisition context of "parents[0]" for 'raise_standardErrorMessage' and 'standard_error_message'. If either of them is not found, the exception is raised -- and handled by the response object in a standard (minimal) way. Otherwise, 'raise_standardErrorMessage(standard_error_message, ...)' is called. The problem which sometimes causes surprises with respect to the used 'standard_error_message' lies in "parents[0]": When the exception happens during traversal, then "parents[0]" is not the object you may expect -- but lies above the expected object. The problem is especially bad when the exception is raised by "request.processInputs". In this case, the traversal did not even start and "parents[0]" is the root object. Consequently, for these exceptions, you will always get the "standard_error_message" from your root folder -- even when the request was targeted to some object deep inside your site. "processInputs" may raise exceptions when you use e.g. ZPublisher type conversions, e.g. ":int" or ":float" and the provided value cannot be converted. If you do not like this, you should not use ZPublisher type conversions. -- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )