Re: [log4perl-devel] Re: logdie / logcroak

[Kevin G. <ke...@go...>]

Very interesting.  I seem to remember reading something in the log4j
docs rejecting the 7 syslog levels, something about them being too many,
confusing, unnecessary. And we don't want to break compatibility with
log4j.  So I don't think we should implement the missing syslog levels. 

We should also keep the details of the level constants private.  Someday
I'd like to allow users to create their own levels (log4j does it with
subclassing), so it would help to keep as many of the details hidden
(therefore changeable) as possible, the user shouldn't count on anything
more detailed than 
	DEBUG < INFO < WARN < ERROR < FATAL. 

But to enable what you're trying to do I can see some useful class
methods to add to Level, what about

get_next_higher_level($level_const){..}
get_next_lower_level($level_const){..}

With the caveat that since log4j defines FATAL as *high* these functions
will actually return the opposite of the priority values, e.g.
get_next_higher_level(ERROR) would return FATAL, which you could then
use to set your logger.

How does that sound?


"Erik W. Selberg" wrote:
> 
> While we're on the subject of levels... :)
> 
> In most of my progs, I have a verbosity setting that's strictly
> increasing. What I'm transitioning them from is:
> 
> % myprog +v +v
> 
> my $v;
> GetOptions("v+" => \$v, ...);
> 
> logdebug(2, "This only prints if $v >= 2\n");
> 
> into:
> 
> $log->info("This only prints if we're at info level, which is normally
> two +v's");
> 
> Needless to say, I've had to reinvent a step function that basically
> counts from 0 3 4 6 7, which is kinda icky. :)
> 
> What's I'd propose is something like the following:
> 
> our %PRIORITY = {
>     OFF        => -1,
>     FATAL    => 0,
>     ALERT    => 1,
>     CRITICAL    => 2,
>     ERROR        => 3,
>     WARN        => 4,
>     NOTICE    => 5,
>     INFO        => 6,
>     DEBUG    => 7
> };
> 
> This is actually the complete list of the syslog(3) levels. Needless to
> say, I'm not sure if we would want to implement
> log->alert / critical / notice (although I would like notice... I tend
> to have three levels of verbosity that's non-error and I'm not a big fan
> of down-shifting to using warn() for one), but it would be nice to
> include so when people specify an integer like 2 for the priority, calls
> to $log->fatal spew something and calls to $log->error don't.
> 
> Whatcha think?
> 
> -e
> 
> 
> Kevin Goess wrote:
> 
> >I agree, and I think that makes all three of us, that logdie should
> >always die regardless of what it logs.  My rationale is this:  A.
> >Programmer is using Log4perl to control whither the messages spew.  When
> >he calls logdie(), he is saying "Please spew this message according to
> >the behavior I have defined for Log4perl, and then die, because my
> >program has encountered a fatal error and must not continue."
> >
> >If A. Programmer has turned logging OFF, Log4perl should spew no
> >messages, including FATAL messages.  We can fix it like this in
> >Level.pm, does that sound good?  (Erik, then we need to adjust your unit
> >tests).
> >
> >our %PRIORITY = (
> >    "FATAL" => 0,
> >    "ERROR" => 3,
> >    "WARN"  => 4,
> >    "INFO"  => 6,
> >    "DEBUG" => 7,
> >);
> >    # Min and max
> >$PRIORITY{'OFF'} = $PRIORITY{'ALL'} = -1;
> >map { ($_ > $PRIORITY{'ALL'} ? $PRIORITY{'ALL'} = $_ : '' ) } values
> >%PRIORITY;
> >$PRIORITY{'ALL'} += 1;
> >
> >    # Reverse mapping
> >our %LEVELS = map { $PRIORITY{$_} => $_ } keys %PRIORITY;
> >
> >
> >
> >
> >msc...@ao... wrote:
> >
> >
> >>In a message dated Wed, 28 Aug 2002 1:47:59 AM Eastern Standard Time, er...@se... writes:
> >>
> >>
> >>
> >>>Here ya go.
> >>>
> >>>
> >>Applied! It's checked into CVS now and will be part of the 0.23 release. Nice work, thanks Erik!
> >>
> >>
> >>
> >>>An interesting question is, assuming that OFF does turn even FATAL off,
> >>>is what the behavior of logdie / logcroak / logconfess should be.
> >>>
> >>>Should they still die, just not log anything? Or should logging OFF
> >>>suppress the death as well?
> >>>
> >>>My own $0.02 would be that the default behaviour would be that they
> >>>still die, as the behavior is really log->fatal && die.
> >>>
> >>>
> >>Good question. I don't think we've made up our minds yet on what log->fatal should actually return -- one solution might be to have it return true if it logs something and false if it doesn't. In any case, until this is resolved,
> >>
> >>    log->fatal && die
> >>
> >>would die randomly, depending on what log->fatal returns. But in this case, if "OFF" does indeed turn of fatal(), die() wouldn't be executed. Tough one.
> >>
> >>I think logdie($msg) should actually be more like
> >>
> >>    log->fatal($msg); die $msg;
> >>
> >>because in most cases this will be called in desperate situations when all you want to do is get out, no matter what the log settings are.
> >>
> >>So, if it turns out indeed that OFF overrules FATAL, we need to make sure your logdie/warn functions still do the right thing.
> >>
> >>--
> >>-- Mike
> >>Mike Schilli
> >>log...@pe...
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>log4perl-devel mailing list
> >>log...@li...
> >>https://lists.sourceforge.net/lists/listinfo/log4perl-devel
> >>
> >>
> >
> >
> >
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> log4perl-devel mailing list
> log...@li...
> https://lists.sourceforge.net/lists/listinfo/log4perl-devel

-- 
Happy Trails . . .

Kevin M. Goess 
(and Anne and Frank)
904 Carmel Ave.
Albany, CA  94706
(510) 525-5217