Review of Jose Armando Garcia Sancio's std.log

[H. S. Teoh]

On Thu, Feb 16, 2012 at 06:49:41PM -0700, Jonathan Stephens wrote:
> > I think this is way too many levels. Why not just define few levels
> > (around three) and let the user define new levels when needed.
> 
> I agree this is too many level, though I think letting the user define
> their own levels is a needless complication.
> >From experience, I would recommend:
>  - CRIT - the application cannot continue
>  - ERROR - the application cannot carry out the requested task
>  - WARN - the requested task cannot be completed normally, but we can
> work around it
>  - INFO - FYI. Things sysadmins would like to know.
>  - DEBUG - For developers debugging.
>  - TRACE (maybe) - also sometimes called fine or verbose - for
> developers debugging.
[...]

>From my experience, such a proliferation of log levels is rarely used
correctly. Most people, sadly to say, can't be bothered to read the
definitions of what each level is supposed to be, and will just
copy-n-paste the first instance they find. Of course, copying CRIT or
ERROR will quickly get a high-priority bug filed against it, but besides
CRIT and ERROR, the rest of the levels are rarely used properly.

I've seen people use WARN just because they think it's appropriate for
"warning" the developer that a certain condition has happened that might
trigger the bug they're hunting for. Then afterwards they forget to turn
that off, and the log fills up with irrelevant messages.

Similarly, INFO tends to be interpreted as "garbage dump for anything I
might want to know while writing this code, who cares what happens to
those messages afterwards". DEBUG and TRACE are rarely ever used after 4
or 5 developers have had their hands on it, because turning those on
will usually flood the logs with reams and reams of irrelevant messages
from unrelated modules, so most people would stop using it after the
first time.

Bottomline: reduce the number of channels, and let the programmer define
their own channels if they need to. Module-specific channels are the
best, so that you don't get reams of messages from completely unrelated
code. But only the user knows what modules they have, so let them make
that decision.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.