Re: formal debug levels

On Fri, 2007-10-26 at 10:30 +1300, Amos Jeffries wrote:
> > On Wed, 2007-10-24 at 09:53 -0600, Alex Rousskov wrote:
> >> On Wed, 2007-10-24 at 23:45 +0800, Adrian Chadd wrote:
> >> > Syslog type levels come to mind. Have them as bit flags, so you can do
> >> > stuff like
> >> >
> >> > debug(DBG_HTTP_CLT, LVL_NOTIFY | LVL_CRITICAL) ("foo\n");
> >> >
> >> > That'd certainly make it easier for people writing/modifying code with
> >> > debugging statements; they'd know what the labels mean rather than
> >> guessing
> >> > at the numbers. :p
> >>
> >> I agree that names are better than magic numbers, both for sections and
> >> debug levels. However, naming constants is a minor issue, separate from
> >> how to define the levels.
> >>
> >> We could add bit flags for "dumps a lot of data" and perhaps "requires
> >> administrator attention" though. That may simplify the levels
> >> definition.
> >
> > I agree to a point. Bitmasks have advantages (finer-grained filtering)
> > and disadvantages (less useable levels). The biggest challenge is IMO
> > managing to be consistent throughout the code-base.
> >
>
> And THAT dear folks is why the 'grouped' levels I proposed. Rather than
> the usage-size Alex proposed.
>
> People in general are far better at classifying things into groups than
> estimating sizes. Particularly when there is no prior knowledge of the
> popularity of other non-related things (such as future indirect usage
> within a loop) which may impact a size calculation.

The levels I proposed are not based on sizes but on expected frequency
and importance, which is usually well-known. Data dumping should
probably be a flag that does not affect the level (if we need that
control at all).

Alex.
Received on Mon Oct 29 2007 - 10:04:29 MDT