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