Disabling CGI::Carp(fatalsToBrowser)

Spidy has asked for the wisdom of the Perl Monks concerning the following question:

Greetings fellow monks,

I'm writing a script that uses a module dedicated to outputting unique error pages. The script has the line:

use CGI::Carp(fatalsToBrowser);
[download]

at the top of it, so that I can quickly debug problems. However, this means that when my module calls die() inside its error outputting routine, I get "at line 46 of moduleName.pm..." at the bottom of my error page. I need a way to make it so that fatalsToBrowser does not apply to the module, but does apply to the script. Does anyone know how I could do this?

Please note, I have tried using

no CGI::Carp(fatalsToBrowser);
[download]

within my module.

Thanks,
Spidy

My Website
Get Eated!

Comment on Disabling CGI::Carp(fatalsToBrowser) Select or Download Code

Replies are listed 'Best First'.
Re: Disabling CGI::Carp(fatalsToBrowser) by tilly (Archbishop) on Sep 14, 2006 at 18:14 UTC
I think that people are solving the wrong problem. If I am not mistaken, your issue is that you are dying in the module, and this information does not tell you where in your program the problem is. The right solution to this is to change the module to use Carp's croak or confess function rather than dying. The croak function will try to figure out where in your script the fatal call came from. The confess function will give a complete stack backtrace, which will include both the line in the module and the line in the script. If you don't want to change the module, a quick hack to make dies confess instead looks like this: `use CGI::Carp; use Carp; BEGIN { $CGI::Carp::WRAP++; $SIG{__DIE__} = \&CGI::Carp::confess; }` [download] (The output may look very awkward if the die came from a carp or confess.) Random note. While fatalsToBrowser is great for development, you should disable it before going to production. Else it makes any security hole much worse by providing useful information for attackers to use to "debug" their attacks on bugs in your software.	[reply] [d/l]
Re: Disabling CGI::Carp(fatalsToBrowser) by sgifford (Prior) on Sep 14, 2006 at 17:37 UTC
It looks like CGI::Carp uses the package global `$WRAP` to decide whether to print errors to the browser. So the quick-n-dirty way to turn it off is: `$CGI::Carp::WRAP = 0` [download] To only hide warnings in your module, you could localize the effect, by putting at the beginning of each `sub`: `local $CGI::Carp::WRAP = 0;` [download] This will reset the flag to its previous value when that sub finishes. Longer-term, you could write a patch to make this more formal, and submit it to CGI::Carp's author. -- sgifford's Web page	[reply] [d/l] [select]
Re: Disabling CGI::Carp(fatalsToBrowser) (upgrade) by tye (Sage) on Sep 14, 2006 at 17:31 UTC
Upgrade to a newer version of CGI::Carp that knows to check $^S. Alternately you could use `local( $SIG{__DIE__} );` which I think will work to temporarilly disable CGI::Carp from catching die calls. Update: Wow, I could've swore I read "eval block" in the original question. See tilly's answer. - tye	[reply] [d/l]
Re: Disabling CGI::Carp(fatalsToBrowser) by robartes (Priest) on Sep 14, 2006 at 16:37 UTC
Hmm, I can think of a way, but I don't see why you would want to do this. CGI::Carp does its `fatalsToBrowser` magic by setting `$SIG{'_DIE_'}`. You could conceivably set $SIG{'_DIE_'} back to do nothing each time you go into the module, and set it back afterwards, but I have no idea whether that would work at all. If I get some more time tonight I'll see if I can rustle up some example code. CU Robartes-	[reply] [d/l] [select]