in reply to Error reporting from web/mail scripts.

You say:
> 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.