I agree wholly with ichimunki but would also like to add these points.

Again, conveying information like "database failed" is not useful to the user- so why print it? I do agree that printing an error in the middle of the page is ugly, so you don't want that either. If one does end up using something like that, then that person deserves to have it ugly because this person obviously did not do enough user input checking. The Tip of the Week:

• Check user input for validity. Use taint mode.

If the input passes a regex or some other test mechanism, let it through, otherwise alert the user that the input was invalid and throw that input away. Don't try to munge it or morph it into something useful- just nuke it. If you check your user input enough you should NEVER encounter a situation where you need to print an error message after printing out 50 rows of a table. If checking the input against a DBI-execute call is necessary, then do it. No sense in wasting your time later trying to figure out what happened.

It may also turn out that your first user input check fails on multiple counts. This is all the more reason to log every error with specifics of the current variables information perhaps using Data::Dumper. That way, if an error along the way does occur, then you can immediately see and fix the problem.

Take an example from perlmonks- don't hand out free error information. vroom is kind enough to send us seemingly uninformative integers as error "numbers". Apparently, he is able to run such number reports through a munger to retrieve some information about the error. At most, say, "Temporary System Failure" or something along those lines.

Good Luck!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.