There can be good reasons for certain exceptions (accidental pun) but in general always RaiseError. Software that is broken should act broken. I'd always rather explain to a customer why an app stopped working over why an app put orders in the bit bucket for two weeks or sent reports with incorrect information while acting like everything was running fine.

I too agree to RaisePetPeeve. Most of the times if we try to delete 3 things as zwon mentioned and 1st and 3rd delete and 2nd record not getting delete due to some constraints, we may not known exactly in big application and it will create problem later. So, rather use RaiseError find the issue(constraint issue or whatever) and fix the problem.

In general, RaiseError is a good idea. However, if, as an example, you were developing yet another Object-relational mapping system, you may want your objects to handle the errors, so you'd turn both PrintError and RaiseError off, and then check for errors and maybe throw an exception as appropriate, for the caller to handle. Since this is another full-fledged exception object at this point, you won't run into zwon's issue of figuring out what type of error it is, and can just handle it appropriately.

Once you've started down this road, perhaps you find problems that your ORM isn't handling quite right, so you want to know what the problem is. You may want to simply enable PrintError in a single location (the connect), and then watch the console for errors. Once you figure out what you're not handling correctly, you can add in the logic, and then turn it back off.

Of course, I'm just grasping at straws here - there are infinite reasons for wanting to do things, not all of them good reasons. But I don't know which, if any, might apply to your situation.

I usually use RaiseError as it allows me not to check error condition after every DB operation. If I don't want script to die after error I always can catch exception. Compare these examples:

$dbh->do(...) or handle_error();
$dbh->do(...) or handle_error();
$dbh->do(...) or handle_error();
$dbh->do(...) or handle_error();
[download]

or

eval {
    $dbh->do(...);
    $dbh->do(...);
    $dbh->do(...);
    $dbh->do(...);
}
if($@) {
    handle_error();
}
[download]

But sometimes you have to mix db operations with others and you want to be able to distinct db errors from lets say IO errors. In this case RaiseError may be not so convenient. E.g.:

use Fatal qw(open);

eval {
    $dbh->do(...);
    open my $fd, "<", $file;
    # some other stuff
}
if($@) {
    # and here we can't say if it was DBI problem or open
}
[download]