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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
