CGI::Carp die with status

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
$SIG{__DIE__}.

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:

Perl-Skript:
---------------
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/Carp.pm 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
them.

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()
method!";
   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?

Thanks!

Irv

-- 

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 dtest.pl
Error
$ echo $?
0

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 dtest.pl
Error
$ echo $?
255

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

$SIG{__DIE__}...
close STDERR ;

Then I get a different result still:

$ perl dtest.pl
Error
$ echo $?
9

*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!]

Thanks!
   /Bernie\

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