http://bugzilla.spamassassin.org/show_bug.cgi?id=3701
------- Additional Comments From [EMAIL PROTECTED] 2004-08-19 13:18 -------
Subject: Re: clean up debugging
> You're actually mixing debugging and logging here yourself ;-)
No, I'm only talking about the die/warn/dbg APIs used in our code. How
syslog handles them is a separate issue. My bug did not mention logging
once. The IRC chat log did, but I thought it would be too confusing to
include it, so I left it out.
> I neither like the idea of of overloading the dbg() call to do ERROR
> and WARN
syslog is a separate issue. Please put it in a separate bug.
> (then use log() instead but that has the disadvantage that we
> can't replace it with a NOOP if debug is disabled) nor the dbg
> ("facility: foo") suggestion. It's much cleaner (and probably faster
> because no RE match is needed) to do it in two params.
You only need to do the RE match if debugging is turned on at all. If
it's not, then it's not needed. No second parameter is needed.
> For the level, using different functions for each level is probably the best
> way (IMO). I'm not sure if we need syslog's plaethora of levels, I think the
> following are enough (judging from syslog(3)):
> die() -> EMERG (or ALERT?)
> err() -> ERR (non-fatal error)
> warn() -> WARNING
> log() -> INFO
> dbg() -> DEBUG
I agree, except that's too many. Let's start with 3 functions. If we
need more, we can add them later. However, the mapping of function to
syslog level is not something I was proposing. I've closed this bug and
opened another. Please use a separate bug for the syslog changes. My
bug is independent of using stderr or syslog.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
