On Wednesday, Sep 24, 2003, at 09:23 US/Pacific, Randal L. Schwartz wrote:
[..]
www.tpj.com - the Perl Journal, formerly a print quarterly, then bundled[..]
with SysAdmin, is now back as an online monthly.
I have a column there, taken over from "brian d foy", who is currently in Iraq under military orders until next April.
p0: I look forward to the Article!
p1: I think Nestor did two good things
a. note a concern about the CGI::Carp technical bug
b. raise the general problem of when is it time to
'unattach' from canonical CPAN Modules. And in particular
surface the 'is the cgi ready for production' general issue.p2: There is a less well known feature in CGI::Carp that might have been addressed - as folks will note at the bottom of the 'perldoc CGI::Carp' - there is a 'set_message()' that COULD have been the fast work around for 'going to production':
use CGI::Carp qw(fatalsToBrowser set_message);
BEGIN {
sub handle_errors {
my $msg = shift;
print "<h1>Oh gosh</h1>";
print "Got an error: $msg";
}
set_message(\&handle_errors);
}And we should all graciously apologize to Nestor if that was the Strategy that they had used; for clearly they had read the POD, and it was Good.
note: the $msg is the 'die line' and could be 'fixed up'
BEGIN {
sub handle_errors {
my $msg = shift;
print "<h1>Oh gosh</h1>";
$msg =~ s/at.*line\s*\d+.*$//;
my $paragraph = "<p>$msg</p>";
print "\n<p>Got an error:</p>\n<p>$msg</p>\n";
}
set_message(\&handle_errors);
}This seems to be a good enough solution IF one is only writing a few simple CGI scripts - and for each one all of the possibilities are nice and neatly contained...
But that way leads to having a 'common' BEGIN block for each piece of cgi code.... WAY TOO MUCH WORK.
p3: But if One is Already in the process of building out a 'handle_error()' - why not simply park them where they are really needed and 'integrate' them into the flow of the general code and design pattern.
Especially if one's CGI code has evolved into using modules as a core part of the process.
To help illustrate this, I have a function get_from_server() that I built out of bits, and those bits use 'die()' in cases where it 'should just die'. So one wraps the call in an eval block, sets a local 'signal handler' for the '__DIE__' and checks how things went.
our ($page,$h) ;
our $wrapper_flag = 0;
our $bytes_read = 0; eval {
local $SIG{'__DIE__'} = sub { $wrapper_flag = 1;} ;
($bytes_read, $page, $h ) =
get_from_server($host_port, $uri, $q);
};In this case I do not really need to know if $@ was set or not and return an 'error' to the caller if we died, or the stuff that is really useful.
return({ runtime_error =>
"Problems connecting to $host_port got status: $@" }
) if ( $wrapper_flag );
....
\$page;This way all of the cgi code that will come through this module has to deal with the fact that exception handling is going to be built in, and that they will be on their head what they do with the exception being passed back to them....
ciao drieux
---
ok, so I liked Randall's general write up better, as he is a good writer... but as a Code Monkey.... well, sometimes more than one way of presenting the solution space may help FLOG THE PROBLEM....
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
