Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Martijn Faassen wrote:
>>>> Hi there,
>>>> See the following proposal:
>>> +1, as posted in a comment already.
>>>> To be determined is whether we want to keep the rules currently in place
>>>> for the SiteError log and apply them to the error reporting utility as
>>>> well, or remove them for the SiteError log as well. I'd propose the
>>>> latter - it's evidently not an issue that all errors are reported in the
>>>> utility, so why suppress them in the logging?
>>> I'd be fine with that, but we'd still need to filter UserErrors,
>>> NotFound, etc. logged.
>>> UserError is thrown by a piece of software when it wants to know the
>>> user of the application about it (e.g. invalid container names). Such
>>> errors aren't of interest for the system error log, at least not
>>> normally.
> Zope2's experience argues otherwise.  Having a log of the error allows
> the developer to investigate an error reported by the user, even though
> the user can't give enough information to allow reproduction.  *I* want
> to be able to push such errors to the log;  *you* might never need to.
> Ergo, it is policy, and needs to be managed as such.

Yup. I said "at least not normally". Zope 2 by default also ignores
Unauthorized and NotFound. Because they're not of interest for the error
log, "at least not normally". :)

>>> NotFound errors would occur every time IE tries to find
>>> favicon.ico, so again, not very useful...
> That is more policy, though, and should be settable on the error log.
> Sometimes getting the log of the NotFound is *important* in some cases,
> even though it is useless most of the time.  This is an anti-case for
> "emergent" behavior configured by adapters, IMHO;  better to configure
> the "service" (the error log object, or its global equivalent) to handle
> such choices.

I agree it's policy. The current policy is to check for
ISystemErrorView. That's obviously not a very flexible policy and it
apparently causes errors to get eaten. Martijn wants to "fix" this by
getting rid of the policy altogether (and in the next Zope 3 version,
implement the proposal which puts the policy largely in the hands of the

I'm actually on your side, telling Martijn that we do need a policy
(which by default should filter UserError, NotFound, etc.). If the
ISystemErrorView policy isn't sane, something else will have to replace
it in Zope 3.3 until we fix this correctly in Zope 3.4. But having
UserError and NotFound always be logged isn't a good choice.


Zope3-dev mailing list

Reply via email to