in reply to use CGI or die;

Another huge debugging benefit of CGI is CGI::Carp 
use CGI::Carp qw(fatalsToBrowser);

[download]
This is invaluable for figuring out a CGI problem. Not only do you see errors, but you can easily insert your own die(); statements to see what's going on, instead of printing your own header and HTML in several lines.

Replies are listed 'Best First'.
Re: Re: use CGI or die;
by davorg (Chancellor) on Jan 12, 2001 at 15:09 UTC

    But you don't need to be using CGI in order to make use of CGI::Carp.

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

[reply]
Re: use CGI or die;
by epoptai (Curate) on Jan 14, 2001 at 12:38 UTC
    I always use strict, -w and fatalsToBrowser when developing, but today this caused me a huge headache in a simple script (with no syntax errors) that merely reads a file, formats the contents, and displays the html.

    It runs fine from the command line (with a few uninitialized value warnings) and could save the output with 

    perl foo.pl > foo.html

    [download]
    but it would just whirl and give no output via CGI. I found that the code looks and behaves perfectly via CGI unless both -w and fatalsToBrowser are enabled! Shut either one off (leaving the other on) and it works fine.

    I found a certain loop in the program that seems to cause this by throwing pairs of =cut around, but the loop seems mundane and similar to the others.

    Is this odd interplay between -w and fatalsToBrowser documented?

    Update: I said i'd node the entire script to craft in a day or two but am finding it difficult to abstract a simplified example. So i'll just suggest that if your error-free cgi script mysteriously hangs, turning off either -w or fatalsToBrowser may help.

    dws - Try this for a good html ™: 

    &#153;

    [download]
[reply]
[d/l]
[select]
      Show us the code!

      Enquiring Monks Want to Know™

[reply]

In Section Meditations