[cgiapp] CGI::Carp - to Use or Not to Use (fatalsToBrowser) - RFC on new wiki article

Dave Baker davebaker at benefitslink.com
Fri Apr 17 23:18:43 EDT 2009


When starting a new CGI::Application project I often get stuck asking 
myself whether I should "use CGI::Carp qw(fatalsToBrowser);"

Typically I'd use the CGI::Carp module when doing CGI development that 
doesn't involve CGI::Application, because it lets me see, on a single 
browser screen, compile-time errors caused by dumb syntax mistakes and 
the results of "die()" statements in the script. That keeps me from 
needing to watch the server error log.

CGI::Carp doesn't seem to play nicely with CGI::Application, because it 
is stopping CGI::Application from reporting the line number in the 
application module at which a die() occurs inside a runmode. Instead it 
reports some line number inside Carp.pm.

This happens whether or not a runmode is specified to handle errors that 
arise inside any runmode (via the $self->error_mode() method inside 
setup() ).

So with CGI::Carp I can get all compile-time errors and runtime errors 
reported on-screen but I lose important line-number information about 
most runtime errors. I can get most runtime errors reported on-screen by 
specifying an error mode, so I don't need CGI::Carp for that.

I've decided CGI::Carp isn't worth the trouble when using 
CGI::Application for development. I'll live with needing to consult the 
server's error log when the dreaded '500 Server Error' appears upon 
refreshing the script's URL after having made a change to the code.

I have made an attempt to think though this, on a wiki page at:

http://www.cgi-app.org/index.cgi?CGICarpUsage

I hope it's useful, or that you'll correct it as needed.

Thanks,

Dave Baker


More information about the cgiapp mailing list