[Zope3-dev] Re: proposal: error reporting unification

[Philipp von Weitershausen]

Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Tres Seaver wrote:
>>>> Philipp von Weitershausen wrote:
>>>>>> Martijn Faassen wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>> See the following proposal:
>>>>>>>
>>>>>>> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ErrorReportingUnification
>>>>>> +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
>>> IErrorReportingUtility).
>>>
>>> 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.
> 
> One of the things I think Zope2 gets right here is that the policy may
> need to be changeable "transiently", i.e. by tweaking the UI of the
> logging service, without requiring changes to zope.conf / ZCML and the
> requisite restart.  I'm arguing for that kind of UI-driven tweak, as
> well as for centralizing the responsibility for the policy into the service.

I agree and as far as I understand Martijn's proposal correctly, he
wants Zope 3 to mimic that behaviour. Zope 3's IErrorReportingUtility
(of which the local, peristent variant is the equivalent to Zope 2's
error_log) would be in charge of this policy. Since it's local and
persistent, it has a UI (which is, btw, very similar to the Zope 2 one,
even right now) which would allow you to tweak it on-the-fly.

Of course, this local error utility wouldn't always be available (though
only in the rare case of having a root folder that's not a site and
doesn't have an IErrorReportingUtility; the default root folder does
have all that). That's why it might make sense to add a global fallback
utility. Dunno how that would decide policy, perhaps it'd be hardcoded
(since it's only a fallback anyway).

Philipp