in reply to Running with warnings on a remote server
use CGI::Carp qw/fatalsToBrowser/; die "Something bad happened";
Fatal errors will now be echoed to the browser as well as to the HTTPD error log. CGI::Carp sends a minimal HTTP header to the browser so that even errors that occur in the early compile phase will be seen. However, with this method, non-fatal errors will still be directed only to the HTTPD error log (see below).
$SIG{__WARN__} = sub { print STDOUT "Content-Type: text/plain\n\n"; print STDOUT @_, "\n"; exit 0; };
This of course could be combined with the CGI::Carp module as follows:
use CGI::Carp qw/fatalsToBrowser/; $SIG{__WARN__} = sub { die @_; };
The problem however with this approach (and indeed the other anonymous subroutine described) is that non-fatal script warnings are treated as fatal errors - This of course will tighten up your code, but is admittedly quite a zealous approach to the matter. A cleaner method may be the incorporation of this trapping into an email reporting function, which sends the script warnings (along with a dump of environment variables and configuration arguments) to you via email rather than to the browser screen in a fatalistic fashion. eg.
use CGI::Carp qw/fatalsToBrowser/; use Mail::Mailer; # Rough code follows, not to be used in current form $SIG{__WARN__} = sub { my $smtp = Mail::Mailer->new("smtp", Server => "127.0.0.1"); $smtp->open({ 'To' => 'webmaster@your.domain.com', 'From' => 'nobody@your.domain.com' }); print $smtp @_, "\n"; $smtp->close; };
Ooohhh, Rob no beer function well without!
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: Running with warnings on a remote server
by Fastolfe (Vicar) on Nov 04, 2001 at 21:11 UTC |