in reply to Re^3: Perl module to get warn or die to render as HTML
in thread Perl module to get warn or die to render as HTML

I'm not sure I really agree with this. While most of my applications are for internal customers (and so I don't worry too much about the point tilly raised), it seems to me that if you have a lot of warning chaff in your logs, the solution is to fix the warnings, not suppress them. I generally leave CGI::Carp directives like 'FatalsToBrowser' in effect for my web apps -- I'd much rather my internal customers get an intelligible error message than something less helpful, if only so that when they e-mail me about it, I can start thinking about the cause of the problem immediately (without sifting through the logs). I think it also helps my customers to see that when errors happen, they're for a reason (and sometimes are because of other dependent systems, and therefore not entirely my fault). :)

Of course, OfficeLinebacker may have been talking more about suppressing debug stuff, which can be configured nicely with things like Log::Log4perl.

  • Comment on Re^4: Perl module to get warn or die to render as HTML

Replies are listed 'Best First'.
Re^5: Perl module to get warn or die to render as HTML
by OfficeLinebacker (Chaplain) on Sep 26, 2006 at 14:12 UTC
    I don't mind leaving FatalstoBrowser on either because I, too, program mostly just for internal customers. I like your term "warning chaff."
    The stuff I see that irks me is stuff like the following line, repeated with the exact timestamp and line numbers/FH names like 20-50 times:

    [Mon Sep 25 15:33:37 2006] securityQuery.cgi: Use of uninitialized val +ue in concatenation (.) or string at /var/appl/httpd/cgi-bin/ms/secur +ity/securityQuery.cgi line 154, FILE line 122.

    Sorry, feeling a little grumpy today. Also I used to be one of the worse offenders.

    I just thought of one last tip--if you do use CGI:Carp and want to send warnings to the browser, don't forget to put your

    warningsToBrowser(1);
    statement after you've written the headers.

    T.

    _________________________________________________________________________________

    I like computer programming because it's like Legos for the mind.

      Right. But in most cases, warnings like the one you cited can and should be corrected in production code -- if you're trying to manipulate a value and it is undefined, then you haven't really trapped for the possibility that the value you're handling is somehow not yet populated, which can lead to more serious problems.