On Tuesday, Jul 29, 2003, at 18:36 US/Pacific, LI NGOK LAM wrote: [..]
[..]
So...... if I create my own style of "fatalsToBrowser". Is that possible to do in this way :
The reason that 'fatalsToBrowser' and the rest came about is because many perl modules are built on 'die' or 'Carp'.
And that 'die' would make the foo.cgi code 'exit abruptly' and that would generate a 500 error.
So if the code you are building on does not do a 'die', 'Carp', 'Croak' - then you really do not need to 'worry about it'.
What you will want to learn about is how to set a local signal handler - if you want to write your own. I built some stuff ontop of some code that I knew had a series of places where it would invoke 'die' - since that code was not 'designed for the web' and in those case 'dying' was a good thing - so the wrapper call solves it:
sub wrapper_call
{
my ($me,$host_port,$uri,$q) = @_;
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);
}; return({ run_time_error =>
"Problems connecting to $host_port got status: $@" }
) if ( $wrapper_flag );
return({ run_time_error =>
"Server $host_port Returned: $h->{dtk_status}"})
if ($h->{dtk_status} !~ /OK/);
return $page if ($bytes_read);
\$page;
} # end of wrapper_callIn this case the caller either gets the reference to the page, or a reference to a hash, that has the 'run_time_error' message in it...
This way if the caller wants to report out the error case then they can do that, or they can also decide that they do not care that the error occurred, and go on to some other strategy...
ciao drieux
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
