I would like to have a more structured way of reporting database errors

Me too! :-)

A recent consulting assignment I had had me refactoring legacy Perl code that was very heavily database access. Since the user interface to the application was a browser and PHBs were the target audience it was very undesirable to have raw error messages to be seen by the end user.

Further the requirement was to alert support staff depending on the severity of the error either by SMS or email. In any event all errors and warnings were to be logged with log rotation and retention.

So what's a Perl Monk to do?

There is nothing truly special about die that it can't be replaced by a home grown sub. Here is an example:

The constant SEV1 was defined by a use constant invocation
along with other severity levels. Since we are experiencing some form of connection issue to the database we want to halt further execution of the code. A severity 1 issue in my client's application was cause to not only alert the developers of an issue, but the DBAs and SysAdmins. (That's the logic I did not show in the sub above)

In this case we are going to send email to the developers letting them know a query failed. Since the end user has many ways to influence the query it might be a PEBKAC or it could be a real coding issue. Either way the developers need to know about it.

Stuff I didn't show (besides the priority logic in full) is the fact that I prepend all messages with __PACKAGE__ so the developers know where the prepare failed since there were about 50 home grown packages in play. I also when writing to the logs prepend the long version of the date and time of when the error was reported.

In addition to what others had said you might find HandlError useful. If you want to see all the things you can find out about an error look at DBIx::Log4perl module's error handler (look for _error_handler sub in DBIx::Log4perl::db.

I would suggest you throw an exception when an error occurs. You don't need if blocks if you do it with objects. Then you wrap this in a try-catch block, see module TryCatch

Basically you "try" your code, you "throw" an exception object when you have an error and you "catch" the error for displaying it elegantly. You catch block should be able to process any kind of exception. You code would be more generic like that.

You can build your own exception classes but I suggest you take a look on CPAN, there is plenty of exception modules.

There are no stupid questions, but there are a lot of inquisitive idiots.

In my code, there is a class which descends from a statement-handle and which incorporates this kind of specific error-checking into it, throwing an appropriate structured error object which might contain properties of its own. The checking of DBI return-codes and so-forth is used but it only occurs in one place. You don’t have to check if the statement succeeded because an exception (object...) will have been thrown if it didn’t.

In fact, the entire app is built around the principle of, “if you screw up, you won’t make it out of here alive.” Even user-errors cause exceptions to be thrown, to be caught if necessary at the highest levels of the program. Some logic catches one error, then re-throws another, in exception handling blocks that are built like the layers of an onion. The handling of exception cases, if you will, is now no longer “exceptional.” It has a very well defined path that is consistently followed. The nested class-hierarchy of error objects naturally provided by Exception::Class is used to good effect.

The outer-level logic contains a try block (which is syntactic sugar provided by Try::Tiny), which looks for these exception classes. If the logic succeeded, it makes it all the way through; if it doesn’t, it winds up in the catch-block, and in its catcher’s mitt comes an object of a particular recognizable class with particular and predictable properties. (If “a string” is caught instead, it’s known to be a bad-bug of some sort.)