One thing to keep in mind is the difference between development/debugging error messages, and the user friendly error messages that should be displayed to actual users. Most users don't know what to do with a stack trace or a DBI error message - and as someone else already mentioned, that can be a security risk. Useability folks will scream if you mention anything technical in an error message.

On the other hand, carp, die() and company are your friends during dev.

I like to wrap most everything in eval{} blocks so that major errors can be wrapped with user friendly text, and uses UNIX::Syslog to log error messages. This gives me the chance to grab the $DBI::errst which typically has some great debug info in it for db errors.

This works great for production, but we tend to leave the eval{}'s out while first coding something - verbose error messages are a big help while debugging. Unfortunately, doing anything as a two pass operation means sometimes the eval{}'s don't get added before it goes to production.