Christian Theune wrote:
Martijn Faassen wrote:
I was making the assumption that any error that shows up in the error
reporting utility in the ZMI is also copied to the SiteError log
(typically STDOUT in a standard Zope 3 configuration), and vice versa.
This assumption is true in Zope 2, where in the error_log object you
can actually request the error to be logged to the shell as well.
It however does not appear to be the case in the error handling logic
in Zope 3. Instead, all errors appear to be logged to the error
reporting utility, but only errors that:
* have views
* have this view provide the ISystemErrorView interface
* and have a method on this view isSystemError() returning True
appear to get logged to the SiteError log (and thus STDOUT).
In certain circumstances this leads to errors that do not appear on
STDOUT that do get logged into the error reporting utility. This is,
at least to me, rather surprising.
What's the motivation for the differences? Could we unify this
approach so that the error reporting utility is responsible for
logging to the SiteError log as well?
+1 for unification
a) it's easier to understand
b) in general favor of unification with Z2
The question I'd like someone to answer is why the system goes through
the checking of views, isSystemError, and such, before it actually logs
an error. I can see the benefit in being able to supply an error view
that handles the error completely, and thus no logging takes place, but
I wonder whether this is in active use, and why in that case even such
errors end up going to the error reporting utility.
I.e. should we unify towards the simple case, or should we be unifying
towards the case where something like isSystemError can be defined?
Note that there's also a whole machinery, independent of this, to
actually have exception side effects, something that the Zope 3 core at
least doesn't appear to be using. I wonder whether anyone uses it, and
if not, whether we can get rid of it completely.
Zope3-dev mailing list