Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Having problem with handling DBI error in object

by perlCrazy (Monk)
on Jul 19, 2007 at 21:07 UTC ( #627624=perlquestion: print w/replies, xml ) Need Help??
perlCrazy has asked for the wisdom of the Perl Monks concerning the following question:

Hi monks,
Below is code that I have written, and want to handle DBI error so that from outside of package I can check :
If method doesn't return anything then print $obj->{ERROR_STR}
sub new { my $class = shift; my $self = bless {}, $class; my $dbh = shift || return (undef); $self->{dbh} = $dbh; # store the dbh for future use return $self; } sub getDDL { my $self = shift; my ($dbase,$tableName,$tableDtls) = @_; return (undef) if (!$dbase or !$tableName); my $tabDtlSql = qq/ ##some sql query /; my $tabDtlSth = $self->{dbh}->prepare($tabDtlSql); $tabDtlSth->execute or $self->{ERROR_STR} = "Can't execute SQL sta +tement: $DBI::errstr\n"; if ($self->{ERROR_STR}) { return (undef); } else { ## do some stuff... }
I am storing the error in ERROR_STR via hash. I have doubt:
if from other methods(other than getDDL) another sql query will get called and that fails then here $self->{ERROR_STR} will have value, and behave differently.
How should I handle the error and store so that from out side I can access error like :
$obj->{ERROR_STR} and ensure that it pronts the correct error, not from other sql query? Pls. advice.
Thanks in advance for help

Replies are listed 'Best First'.
Re: Having problem with handling DBI error in object
by ikegami (Pope) on Jul 19, 2007 at 21:18 UTC
    Just read $obj->{ERROR_STR} before doing stuff that might change it, just like you do with $DBI::errstr. Alternatively, throw it as an exception.
      u mean like this :
      $obj->getDDL(); if (!$obj->{ERROR_STR} { ##call other method }
        if (!$obj->getDDL()) { ##use $obj->{ERROR_STR} } ##call other method
Re: Having problem with handling DBI error in object
by jZed (Prior) on Jul 19, 2007 at 21:25 UTC
    I'm not sure what you're trying to accomplish that leaving RaiseError off and PrintError on wouldn't accomplish. By checking only the execute() and not the prepare() you may, depending on the driver, be losing the actual cause of the error. Also, while $DBI::errstr should work in most situations you are better off using the errstr most closely associated with the object in questions, $dbh->errstr for prepare and other database handle methods $sth->errstr for execute and other statement handle methods.
      Thanks for reply. If any error happens then I don't want to die the program. If any $DBI::error then store and then access that error via calling program.
      This is what I want to achieve. Just want to ensure that {ERROR_STR} should not have another error value if calling some other method.
        > If any error happens then I don't want to die the program.

        With RaiseError=0, and PrintError=1, that is just what will happen - the error message will be printed but the program will not die.

        If you run $obj->method1() and store its error message in $obj->{ERROR_MSG} and then run $obj->method2() which also stores its errors in that same place, yes you will overwrite the previous error. If you have that situation, you may need to store the errors in a hash with e.g. a timestamp as the key to the various errors. You might want to look at some of the modules used for DBI logging and tracing.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://627624]
Approved by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2018-04-25 11:45 GMT
Find Nodes?
    Voting Booth?