[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