If eval id not a viable solution, then you have to check every DBI call, but only after you instruct the DBI not to do anything in case of errors.

#!/usr/bin/perl -w
use strict;
use DBI;
#
# ---- untested 
#
my ($dns, $user, $password) = ("dbi:wathever:db","me","secret");
my $dbh = DBI->connect($dns,$user,$password, 
    {RaiseError=>0 , PrintError=>0})        # <-- be quiet!
or die "can't connect ($DBI::errstr)\n";

my $sth= $dbh->prepare("SELECT WRONG FROM NON_EXISTING");
if ($sth) {
    # fetch your records
    while (my $rec = $sth->fetchrow_arrayref()) {
        print "@$rec\n";
    }
}
else {
    print "something was wrong: ", $dbh->errstr, "\n";
    # deal with the problem here
}
[download]

Notice that you can't use $dbh->errstr after a failed connection, because the result would be an undefined $dbh.

Be also aware that, using this approach, you are entirely responsible for error checking. If you skip a step, the next one will try to execute/prepare/fetch on a undefined handler. You need to test very thoroughly.

Good luck!

Update

HandleError (which has been proposed in other answers) is a generalized error trapping system. If you set it, the DBI will use it before calling RaiseError. It is not a replacement for error checking, since it will handle all the error from a static point, without any knowledge of the program flow.

If you want to do something sensible with your errors, you have to catch them one by one, either by evalling their death or by checking their result.

HandleError can be useful for error logging or to modify/erase error messages before passing them to RaiseError. (The DBI docs offer some examples of that.)

Remember that technological tricks are not replacement for good programming design.

 _  _ _  _  
(_|| | |(_|><
 _|
[download]