In my experience, it's generally not a good idea to leave FatalsToBrowser enabled in production code. There's a lot of discussion of this elsewhere in the monastery, and so I'll not delve into that. I'll also not ask you why are you putting code in a production environment with errors such as that ;)
My lecturing aside. . . check the CPAN documentation for CGI::Carp. There's an excellent example of creating your own error message featured there. I'll repeat it here, however it's no substitute for reading the actualy documentation:
use CGI::Carp qw(fatalsToBrowser set_message);
BEGIN {
sub handle_errors {
my $msg = shift;
print "<h1>Oh gosh</h1>";
print "<p>Got an error: $msg</p>";
}
set_message(\&handle_errors);
}
In a production environment, I remove FatalsToBrowser and instead replace it with custom error handling (and don't let the code go out with compile errors ;) Statements I've known to fail from time to time (database calls, etc.) I instead wrap in an eval block:
eval
{
$sql = $dbh_receipt->prepare_cached($script);
$sql->execute();
$sql->bind_columns(\$receipt);
$sql->fetch();
$sql->finish();
};
if($@)
{
log_error($dbh_receipt->err(),
$dbh_receipt->errstr(),
$script);
}
By processing my own errors, I control exactly what the user sees, and can then log them to a database and even e-mail them to myself so I can look like a good guy to my users when I fix their problems before they have a chance to call me about them.
Granted, this might be overkill for what you are trying to do, and I've probably strayed too far OT from the original question, but you get the point ;)
Hope this helps!
MrCromeDome
| 