CGI::Carp die with status



  • 1. perl vs C for CGI
    Hello, am having a program in C which throws "internal server error" reason is premature end of script headers but i checked my http header & syntax of the program too , its fine. but when am re-program the same in perl it works fine i need to know the reason for the problem with C ,do any memory problem cause this error ,can any suggest me on this.thanks for your time server:apache
  • 2. Template
    Hi, I have this template file that I am opening in my script. <tr> <td>{var1}</td> <td>{var2}</td> <td> <table> <tr> <td>Name: {name3}</td> <td>Age: {age3}</td> </tr> </table> </td> </tr> Are there any good regular expressions to grab each tag and its contents? I'm doing this in javascript, but I'm guessing that there are some really good regex experts in this group. If there are any perl, php, or javascript libraries out there for this sort of thing, I'd like to know about it!
  • 3. Writing row at a time in Excel using OLE
    Hi! I need to write a row at a time or a whole sheet at a time, anything faster than one cell at a time in Excel sheet using Win32::OLE. Can anyone help me? Spreadsheet::WriteExcel module have functions for writing row at a time but I need to modify existing Excel file and the module does not allow that. Thank you in advance!
  • 4. simple regex
    I've got a file with a list of ip's in brackets, fqdn's and -'s. How do you simply remove the [ ]'s and the -'s from the file with a simple perl script. I've thought about using a if statement to take out the -'s lines, then maybe a double split action to get rid of the [ ] backets or regex substition s/// with whitespaces. [] - [] -

CGI::Carp die with status

Postby bernd » Thu, 07 Feb 2008 00:44:38 GMT


Has anyone experience with dying from CGI::Carp with a status?
Using LWP one can catch status with:

$response = $ua->request($req);
$content = $response->content;
if ($response->is_success) {
	print $content;
} else {
	print $response->status_line;

However, when the script "dies" with CGI::Carp the exit status is "200
I'd rather have a status that is not "OK" and not scan the returned
$content for "Software error".

Has someone been able to do this?


Re: CGI::Carp die with status

Postby smallpond » Thu, 07 Feb 2008 01:52:32 GMT

HTTP status is set by the -status value in the header.  If the cgi is
not checking for errors and exits without setting status you will get
the default.  Sounds like it is doing fatalsToBrowser if the error
is showing up in the content.  It will also be in the httpd error log
on the server.

You need to post the cgi if you want help fixing it.

Re: CGI::Carp die with status

Postby J. Gleixner » Thu, 07 Feb 2008 01:53:54 GMT

Where is "CGI::Carp" being used in your example code?  How the
heck is anyone going to be able to help if you don't show exactly
what you're trying?

Show a short example that uses CGI::Carp and produces the error.

Re: CGI::Carp die with status

Postby bernd » Thu, 07 Feb 2008 02:22:11 GMT


Sorry for not being clear.
A simple CGI example script is:

use CGI::Carp qw(fatalsToBrowser);
die "Some error occured...\n";

I would like the status header not to print 200 OK, but e.g.
status 500, server error.

Usually one can set the status, but I do not know how to set the
status header when the script dies with fatalsToBrowser as above.


Re: CGI::Carp die with status

Postby xhoster » Thu, 07 Feb 2008 03:29:15 GMT

Use set_die_handler instead.  That is why it is there--to give you more
control than fatalsToBrowser does.


--------------------  http://www.**--****.com/ 
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
adverti{*filter*}t in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.

Re: CGI::Carp die with status

Postby Owen » Thu, 07 Feb 2008 06:47:24 GMT


    use CGI::Carp qw(fatalsToBrowser set_message);

meet your need?


Re: CGI::Carp die with status

Postby Owen » Thu, 07 Feb 2008 06:52:09 GMT

Meant to add, see perldoc CGI::Carp ---Changing the default message


Similar Threads:

1.$SIG{__DIE__} doesn't make sense when using CGI::Carp

Me and my cgi-script have the following problem.

I'm using the package CGI::Carp (which installs internally some
$SIG{__DIE___} handlers).
In addition my script defines an own handler methods for

My suggestion was, that my definition is "overwritting" the defintion
of CGI::Carp.
But that doesn't seem to be right.

Here is my example:

use CGI::Carp;
 $SIG{__DIE__} = \&myDie;
 sub myDie {
    print "<b>ERROR-Message: $_[0]</b>";
eval {     
  print "Content-type: text/html\n\n";
 print "Just some text<br>";
 die "I'm dying. Please help!";
 print "some text never shown";

When running the skript I get the following message (notice the wrong
module and line number)

Just some text
ERROR-Message: I'm dying. Please help! at
d:/dev_soft/apache/Perl/lib/CGI/ line 301.

So it seems that the CGI:Carp definition of $SIG{__DIE__} is somewhat
alive. It is called before my own signal-handler is activated.

What is the way to undo the CGI::Carp handler definitions?
Just wanna know 1.) why CGI::Carp::die handler is still active when I
overwrite it with my own handler and 2.) how I can
prevent it? 

By the way:
The above example-script simplifies the core problem for discussion!
In real life there are two scripts installed running under mod_perl.
One of it uses CGI::Carp. The otherone defines the signal handler.

Thanks and Greetings! 

2.CGI::Carp::croak's behavior differs from Carp::croak's?

I wonder if someone familiar with Carp and CGI::Carp could explain this 
to me:

I have a module, which I use in several CGI scripts, that has its own 
error function which calls croak.  If I write this module to use Carp, 
it works as I expect: the error is reported at the line where the script 
calls into the module, not the line in the module where croak is 
actually called.  However, if I use CGI::Carp instead of Carp, the error 
is reported at the line where croak is called.  That is, with CGI::Carp, 
croak doesn't seem to do anything different than die!

The code below illustrates the issue.  Am I misunderstanding how 
(CGI::)Carp works and/or misusing it?

#! /usr/bin/perl

use strict;
use warnings;

package Foo;

use CGI::Carp; # or use Carp;

sub error ($) {
     croak $_[0]; # with CGI::Carp, error is reported here

package main;

Foo::error 'This is the error'; # error *should* be reported here
                                 # (and is, using plain Carp)

3.Is it wrong...croak vs die...carp vs warn

On Aug 13, 2:39 pm,  XXXX@XXXXX.COM  (Robert Hicks) wrote:
> I typically "use Carp;" and change my "die" and "warn" statements to
> "croak" and "carp". I have read a couple places croak/carp are a little
> better at telling you what and where than the standard die/warn.

There is no right or wrong here.  croak() and die() are used for two
different purposes.  You use each one when it's appropriate to use

In a subroutine or method, you use croak/carp if the error is
something the caller of your code did wrong.  You use die/warn if the
error is something unexpected in your code.  For example:

package MyClass;
sub new {
   my $class = shift;
   my $name = shift or croak "Must pass name parameter to new()
   open my $cfg_fh, '<', 'MyClass.cfg' or die "Unable to open config
file: $!";
   chomp(my $attr = <$cfg_fh>);
   my $ref = { name => $name, attr => $attr };
   return bless $ref, $class;

If the user forgets to pass the name parameter to your class, you need
to tell the user which call to new() it was that has the error.  The
user doesn't care that it happened in line 4 of your module.

If the configuration file cannot be opened, you want to know where in
your module you attempted to open it so you can see if it has the
right name or whatnot.  You don't care where in the calling code new()
was called.

Paul Lalli

4.Why Carp::croak over die?

I often come across the advice to use Carp::croak instead of die,
presumably because croak reports the error "from the perspective
of the caller", but I don't understand why this is generally
considered so much better.

If I'm interested in the caller's perspective, I use the Perl
equivalent of try/catch (i.e. eval/if($@)).  This gives me access
to information both about the caller *and* about the called function.

Am I missing something?




5.Exit status from 'die'

I'm trying to use a __DIE__ handler to manage the 'departure' of my
program and I've noticed a bit of an oddity I'm not sure about to try
to get the exit status to be correct.

Given this scrap of code:

sub Report
{  print $_[0];
   exit $! ;

$SIG{__DIE__} = \&Report ;

die "Error\n" ;

When I run it, I get:

$ perl
$ echo $?

Clearly, $! didn't have the hoped-for value.  If I #-out the '$SIG',
so that die really does "die", then I get what I expected:

$ perl
$ echo $?

So I'm not sure what to do.  If I try a different way to suppress the
die-generated error message:

close STDERR ;

Then I get a different result still:

$ perl
$ echo $?

*SO*  How can I write a 'die' handler that will:
   1) swallow the error message [so it will _not_ be printed to
stderr] AND
   2) exit with the proper/expected exit status

[on (1), an explicit 'exit' in the handler and closing STDERR are the
only ways I've managed to find, so far, to *NOT* have die go and print
the error message to STDERR... if there's a cleaner/less ugly way I'd
love to hear about it!]


6. carp "$!" vs carp "$!\n"

7. why to use 1)use CGI,2)use Strict ,3)use Carp in script

8. CGI::Carp at runtim from Module

Return to PERL


Who is online

Users browsing this forum: No registered users and 82 guest