Log4perl: Using appropriate Log Levels

loris has asked for the wisdom of the Perl Monks concerning the following question:

This does not really have anything to do with Perl, but I suspect that some of you may have encountered a similar problem.

I have a module with a few subroutines which contain the main logic and several utility subroutines which do more or less trivial things. What I offen find happening is that a utility sub will produce an ERROR in the log and then the sub which called it will also log an ERROR, because the utility sub did not produce the expected result. In principle, I would prefer to only see the second ERROR and could just let the utility sub log, say, WARN. However, as the module get more complex, the distinction between 'main logic' sub and 'utility' sub seems to become less clear, and thus it seems more difficult to say what the appropriate log level should be.

I suspect the answer lies in breaking down the module into smaller modules, thus forcing myself to distinguish between different categories of sub, so that I can turn logging on and off for each module separately, but perhaps some of you have other ideas.

Thanks,

loris

"It took Loris ten minutes to eat a satsuma . . . twenty minutes to get from one end of his branch to the other . . . and an hour to scratch his bottom. But Slow Loris didn't care. He had a secret . . ."

Comment on Log4perl: Using appropriate Log Levels

Replies are listed 'Best First'.
Re: Log4perl: Using appropriate Log Levels by tirwhan (Abbot) on Nov 24, 2005 at 09:33 UTC
You could not put any logging into your utility subroutines (except debug logging) and instead throw an exception there. Catch that exception in the main subroutine (`eval`) and handle as appropriate. Your main subroutine is best set to know whether the action that just failed was trivial or very important and can log accordingly. This will also make it easier for you to decide how to classify your subroutines, first-class subroutines handle their errors, utility functions just throw exceptions. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply] [d/l]
Re^2: Log4perl: Using appropriate Log Levels by matt.tovey (Beadle) on Nov 24, 2005 at 15:13 UTC
That's what I was thinking too - when 'open' fails it doesn't "log" the error, but rather sets $! for you and returns false so that you can see that it's failed, and decide whether you want to do something with the error or not. Your utility subs could do the same...	[reply]
Re^3: Log4perl: Using appropriate Log Levels by tirwhan (Abbot) on Nov 24, 2005 at 15:37 UTC
Except that this way is not really ideal IMO. I am a recent Perl Best Practices convert to the idea that you should die/croak on an error instead of returning undef. This means the caller has to explicitly catch the exception (with eval) or his application will die, which in turn means there'll be less cases of forgotten error checks. Using exceptions you can also pass a helpful error message up to the caller, or an exception object which contains useful data. Yes, you'll do a lot of eval'ing, which is ugly, but it's much more defensive programming. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan	[reply]