[Zope] help with customizing error messages, Zope 2.9

[Dieter Maurer]

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