While 'fatalsToBrowser' is great for debugging it should be commented out for production IMHO. The reasons are 1) that it reveals far too much detail to someone who is deliberately hacking your system and 2) does not produce a particularly user friendly message (better than a 500 but not much). I think a die_nice routine (as noted above) is better idea as it lets you kid the user everything is OK while silently logging the problem and/or sending you an email to fix it.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

I disagree to this blanket statement. We use fatalsToBrowser (with a custom message), but we're just very particular about where we let the program die. I can list off all of the die calls for our entire application off the top of my head -- and they're all severe enough to warrant something evil. Die() is reserved for Should Never Happen errors.

So if *we* didn't call die, then Perl must have bailed. Modules I have wrapped in eval {} because I don't want them dying -- ever. (XML::Parser--) This pretty much just leaves compilation errors and if we've put a program onto production that won't compile then we've got much more serious issues than the user seeing an ugly message.