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
>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
>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" (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"
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, ...)'
The problem which sometimes causes surprises with respect
to the used 'standard_error_message' lies in "parents":
When the exception happens during traversal, then
"parents" 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"
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
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -