in reply to Perl module to get warn or die to render as HTML

Take a look at the standard CGI::Carp module and its fatalsToBrowser / warningsToBrowser options.

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

Replies are listed 'Best First'.
Re^2: Perl module to get warn or die to render as HTML
by tilly (Archbishop) on Sep 26, 2006 at 02:55 UTC
    And don't forget to configure things so it is turned on in development and off in production. Else you'll provide an ideal tool to help attackers debug their attacks against any flaws that they find in your site.
      Great point. At my org we have a web server error log and the number of scripts that 'use warnings' that are in production is outrageous.
      So also turn off warnings and debugging in general in production so that other web programmers don't have to sift through 100+ lines of Net::FTP
      debug output to find the line in the error log from their own script.

      T

      _________________________________________________________________________________

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

        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.

        First you should trace out the error log path and see what kind of error it is showing. Than as suggested by monks, you can download the below module from CPAN and use it.

        use CGI::Carp qw(fatalsToBrowser); use strict;

        or if you have more number of lines in your code and to check whether a particular function is been working or not you can see by writing the following 2 lines of code and test.

        print "Content-type:text/html\n\n"; print "here";

        I strongly disagree with this.

        Don't silence the messenger. Leave warnings and debugging on. Actively clean up warnings so that you don't have any spurious warnings. Monitor what remains.

        You'll find that a significant fraction of the time the warnings you get will point to bugs that slipped past development and QA. Often enough to justify the rest of the work.