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

J

Jo Oberman

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!
 
A

Amir Kadic

Jo said:
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.

To me this seems alright: the exception is _raised_
( by calling die()) in Carp.pm, but it is still
_your_ handler that is called.

Or am I wrong?

Amir
 
J

James Willmore

On Fri, 12 Sep 2003 22:37:34 +0200
Jo Oberman said:
$SIG{__DIE__} = \&myDie;
sub myDie {
print "<b>ERROR-Message: $_[0]</b>";

Can be simplified and changed to:
$SIG{__DIE__} = sub{print "<b>ERROR-Message: $_[0]</b>\n";};

Notice the new line character at the end of the line. If it is
omited, then the line number of the error will be printed. Bad move
for a CGI script. The user does _NOT_ need that information.
}
eval {
print "Content-type: text/html\n\n";
print "Just some text<br>";

die "I'm dying. Please help!";

print "some text never shown";
};

Why are you doing an 'eval' here? And, again, no new line in the
'die' statement - bad move.

If the 'eval' is done away with, you get your message .... if you use
the 'eval', you get your message .. so, what's the question again?

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.

Use one or the other, but not both. I posted a similar question about
2 months ago. That's the way I handled it - because the effort to go
through was too much (although, my question related to a script having
a signal handler and the moudle it used and _I_ wrote used a signal
handler and one was over riding the other).

You can override one in favor of the other, but, IMHO, it's more
effort than it's worth.

An alterante method that _may_ work is ...

==untested==
BEGIN{
$SIG{__DIE__} = sub { print "<b>ERROR-Message: $_[0]</b>"; };
}
use CGI::Carp;

eval{
print "Content-type: text/html\n\n";
print "Just some text<br>";

die "I'm dying. Please help!";

print "some text never shown";
};

if($@){die "DIED";}

Here, you're using the BEGIN block to set up the error handling. It
_may_ do what you want it to do. Although, my first thoughts should
apply - use one or the other.

HTH

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
Certainly there are things in life that money can't buy, but it's
very funny-- Did you ever try buying them without money? --
Ogden Nash
 
J

Jo Oberman

To me this seems alright: the exception is _raised_
( by calling die()) in Carp.pm, but it is still
_your_ handler that is called.

Or am I wrong?

Sorry, you are wrong.
I'm reasing the exception in my example. The message should
be something like
ERROR-Message: I'm dying. Please help! at
d:/dev_soft/myDir/Perl/example.pl line 19
 
D

David

Jo Oberman said:
Me and my cgi-script have the following problem.

I'm using the package CGI::Carp (which installs internally some
$SIG{__DIE___} handlers).

this is only partly true. CGI::Carp only overwrites $SIG{__DIE__} if
you use 'fatalsToBrowser'. check the source (inside the import()
function) of CGI::Carp to see what i mean.
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?

technically, you can't. because CGI::Carp does its magic by
overwritting the global die function with:

*CORE::GLOBAL::die = \&CGI::Carp::die;

once this is done, you can never get back the real die function.
CGI::Carp does store the global die function inside one of its
function named realdie().
Just wanna know 1.) why CGI::Carp::die handler is still active when I
overwrite it with my own handler and

your $SIG{__DIE__} handler is still active and CGI::Carp never
overwrites your handler. it's just that your die() function never
really reach the global die function anymore so your handler is never
called. the die function you call in your script goes to
CGI::Carp::die which does not involve your handler.
2.) how I can prevent it?

you can't but you can fake it by saying:

use CGI::Carp;
use subs qw(die);

and then provide your own version of die instead:

sub die{
#--
#-- do whatever you want to do here.
#--
exit(1);
}

die "now this goes to the above die function instead, not
CGI::Carp::die\n";

you can, of course, hack the CGI::Carp code yourself to prevent that
from happening but are you sure you don't think CGI::Carp is doing the
Right Thing?
 
I

Ilya Zakharevich

[A complimentary Cc of this posting was sent to
David
technically, you can't. because CGI::Carp does its magic by
overwritting the global die function with:

*CORE::GLOBAL::die = \&CGI::Carp::die;

once this is done, you can never get back the real die function.

Eh??? What about CORE::die()?

Ilya
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top