in reply to Log4perl: Using appropriate Log Levels

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

Replies are listed 'Best First'.
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]

      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]

In Section Seekers of Perl Wisdom