MARKSTOS via RT wrote:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=42389 >
>
> Thanks for the suggestions Dave. Several of them will appear in the next
> release.
>
> I didn't find the "Directoryfoo_ModuleBar" examples clearer than what we
> had, so I didn't make those relates updates.
>
Thanks, Mark!
I later regretted the grammar-nazi comments re it's
I made a good deal of progress with CGI::Application (trying to get more
serious about learning web apps; I can't keep up with the changes and
the complexity re Catalyst's dispatcher, so I will leave that one on the
vine for now).
I wonder what you think of the attached document I put together
(compulsively) when trying to learn (master; wretched excess) the pros
and cons of CGI::Carp. If it's not too pedantic I'd be happy to put it
on the mailing list.
Dave
--
Use EmployeeBenefitsJobs.com
to find the best jobs and candidates!
and BenefitsLink.com
for the latest news, discussions and events.
Dave Baker, Editor and Publisher
davebaker@benefitslink.com
(828) 587-6373 office (Eastern time)
(828) 507-3955 cell
Effect of CGI::Carp when debugging compile-time errors.
======================================================
1. If "used" in the instance script
"use CGI::Carp qw( fatalsToBrowser )" (which I'll abbreviate
hereafter as merely "CGI::Carp") is helpful for debugging
when used in the instance script and the compilation error
arises in the instance script, in which case fatals do
appear in the browser.
It is not helpful if the compilation error arises in the
application module (in which case the usual 500 error is
shown).
2. If "used" in the application module
CGI::Carp is not helpful for debugging when used only in the
application module, no matter whether the compilation error
arises in the instance script or the application module.
3. Effect on Apache error log
The Perl-generated message about the compilation error is
written to the Apache error log whether or not CGI::Carp is
used in the instance script or the application module, and
whether or not the compilation error is in the instance
script or the application module.
Effect of CGI::Carp when handling run-time errors.
==================================================
If CGI::Carp is used in the instance script, it is helpful
for debugging if a runtime error occurs in the instance
script. But such errors don't happen often due to the
CGI::Application technique of a short instance script that
calls the run() method of an application module. I needed to
use a
"$my_runtime_error_maker = 1/0;"
statement in my instance script to find this behavior.
Using CGI::Carp only in the instance script doesn't work to
display runtime errors in the application module.
But runtime errors are displayed if CGI::Carp is used in the
application module.
By using CGI::Carp in an application module, a runtime error
encountered in the application module avoids the "500
Internal Server Error" screen. Further, the Perl-generated
message about the error ($@) is displayed, usually showing
the line in the application module at which the error
occurred and the line of the instance script at which the
run() method was called. But the important exception is when
the error arises due to encountering a die() or croak()
statement inside a runmode. In that case the error message
helpfully names the runmode in which the error arose but
unfortunately displays an unhelpful line number in Carp.pm
rather than the line number at which the die() or croak()
was encountered.
That quirk seems to arise due to the way CGI::Application
optionally handles a die() or croak() inside runmodes.
CGI::Application makes available to the programmer a
error_mode() method. Invoking error_mode() with the name of
a subroutine causes that subroutine to become the runmode
when die() or croak() is encountered. For example, a line in
the application module's setup() method might be:
"$self->error_mode( 'your_sub_here' );"
The programmer can write the 'your_sub_here' subroutine to
display a generic message to the web browser, display the
contents of $@ (which are sent as the only parameter to the
named subroutine) or take some other action such as sending
an email to the webmaster.
For example, if this statement is encountered:
die( "Unexpected format for input data, stopped" );
then $@ would look something like "Unexpected format for
input data, stopped at /www/cgi-bin/Events/View.pm line 50."
As with CGI::Carp, use of error_mode() avoids display of
"500 Internal Server Error" upon encountering a die() or
croak().
The runmode specified by error_mode() is used when die() or
croak() is encountered even if CGI::Carp has been used
(whether in the instance script or the application module),
so in this sense using CGI::Carp doesn't hurt -- much.
Unfortunately when CGI::Carp is used, $@ as sent to the
runmode specified by error_mode() and sent to the errors log
provides a useless line number of Carp.pm, not the line
number in the application module at which the die() or
croak() was encountered.
CONCLUSION
==========
Avoid using CGI::Carp in an instance script. Catch compile-
time errors by using "perl -cT instance_script.cgi" instead.
This is because the use of CGI::Carp in the instance script
will make error messages significantly less useful if you
decide to use CGI::Carp in the application module being run
by the instance script. More significantly, using CGI::Carp
in the instance script doesn't work to cause compile-time
errors encountered in the application module won't be be
displayed, so it's basically a waste.
It might be wise to use CGI::Carp in an application module
while you're developing your application, as it is with
other Perl programs that interface with webservers via CGI.
By using CGI::Carp in an application module, you'll see
runtime error messages on screen instead of a useless "500
Internal Server Error" screen, no matter what the reason of
the runtime error.
(You could check your server's error message log each time
you see a 500 Internal Server Error screen, but why not see
the error message onscreen during development? Note: when
you're in production, remove "use CGI::Carp" so your program
won't display line numbers and other clues for crackers
displayed to users in the event of runtime errors.)
If you use die() or croak() in your application module -- as
is often done for debugging or to deal with a no-way-to-
recover operational condition -- then you want to use
error_mode(), whether or not you also use CGI::Carp, if:
1. You want the program to do something (e.g., send an
email) when it encounters a die() or croak() in addition to
whatever is displayed to the web browser, or
2. You will be disabling CGI::Carp when you go into
production and you want to create a customized display of
the die() or croak() situation rather than sending "500
Internal Server Error" to the web browser. (But consider
whether the server-default "500 Internal Server Error"
screen just might be best in production because it provides
no clues to a malicious user.)
And, if you use die() or croak() in your application module,
CGI::Carp seems to do more harm than good, because during
debugging it ruins your ability to easily see the line
number in the application module at which the die() or
croak() occurred. That line number isn't shown to you while
using CGI::Carp with CGI::Application, whether you're
watching your error log, watching a screen for CGI::Carp
output, or watching the screen for customized output of $@
by the error_mode runmode.
Although CGI::Carp is nice because it gives you at least
some information for all types of runtime errors, the win of
getting useful line numbers by skipping CGI::Carp is worth
the annoyance of the occasional "500 Internal Server Error"
during development that arises from runtime errors other
than die() or croak().
RT for rt.cpan.org