in reply to Re: Log4perl: Using appropriate Log Levels
in thread Log4perl: Using appropriate Log Levels

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...
  • Comment on Re^2: Log4perl: Using appropriate Log Levels

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