Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

dbi: PrintError and RaiseError

by perlthirst (Scribe)
on Dec 23, 2008 at 13:04 UTC ( #732285=perlquestion: print w/ replies, xml ) Need Help??
perlthirst has asked for the wisdom of the Perl Monks concerning the following question:


From the manual page of DBI, i got the following informations

it will do a warn on an error.
It will do a die on an error.

Can any body explain, in which case we would want to warn on an error and in which case we would want to die on an error.

I think we should always use RaiseError, for whatever error occurs it should do a die.

If anybody have a better understanding about this, kindle explain.

Comment on dbi: PrintError and RaiseError
Re: dbi: PrintError and RaiseError
by Anonymous Monk on Dec 23, 2008 at 15:37 UTC
    Hi, Depends on your code and what it's doing. Dieing is an options, especially on programs that need to run once and have a known way of checking them. If you're writing a long running daemon that is logging to a db then you quite probably don't want to die. Far better to have a period of logging not working than a period of your critical application being stopped!!
Re: dbi: PrintError and RaiseError
by zwon (Monsignor) on Dec 23, 2008 at 19:08 UTC

    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();


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

    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 }
Re: dbi: PrintError and RaiseError
by Tanktalus (Canon) on Dec 24, 2008 at 00:16 UTC

    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.

RaisePetPeeve => 1
by Your Mother (Canon) on Dec 24, 2008 at 01:52 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://732285]
Approved by Corion
Front-paged by Tanktalus
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (9)
As of 2014-10-25 18:42 GMT
Find Nodes?
    Voting Booth?

    For retirement, I am banking on:

    Results (147 votes), past polls