I think that you are correct that fatalsToBrowser is unwise in production code. If it gives you enough information to be helpful during development, then I'm sure it gives enough to help a cracker.

There are two kinds of errors though, application errors, and user errors.

• With Application errors, I think the standard 500 error message is all that the user needs to see, though you can spruse the 500 message error page up if you want - though an email or debug dump to the server log is still wise.
• User error, and here you need to tell the user something so that they can fix their input, without giving a cracker any additional information. I think that when possible this is best caught in the browser with JavaScript and good interface design, before the CGI process starts.

While security through obscurity isn't a viable approach on it's own, there is no point in giving crackers a free ride.

I'm currently working on Perlfect Search which does use fatalsToBrowser, and I'm in the process removing it and making it run under strict.....

My humble 2 credits.