> When you put a web CGI script or an email processing
> script or a cron-run script into production, you can't use
> the standard die and warn functions to get errors because
> the standard error stream goes to some random place.
No, it goes to the webserver error log. I wouldn't call it a random
place, necessarily. :) In my opinion, that's where it *should* go; in a
production system it certainly shouldn't be sent to the browser,
because that could reveal sensitive information and introduce
a security hole.
carp and croak aren't really going to help you here. They
write to STDERR just like die and warn do. The difference is that
they report errors from the perspective of the caller.
You *can*, however, use CGI::Carp. This lets you use a
carpout function to write error messages to a different filehandle
than STDERR. From the docs:
BEGIN {
use CGI::Carp qw(carpout);
open(LOG, ">>/usr/local/cgi-logs/mycgi-log") or
die("Unable to open mycgi-log: $!\n");
carpout(LOG);
}
However, the docs do say that using carpout is a hit on
performance, so it is recommended for development usage only.
If you would like to capture errors and have them sent as email
messages to you, you could use a $SIG{__DIE__} handler, or
you could wrap your script in an eval to catch errors; if an
error occurs, send yourself email with the error message. | 