www.developer.com/lang/article.php/2184681
April 10, 2003 Error DiagnosticsThe ability to trap errors within the DBI is very useful, with either manual or automatic error checking, but this information is only marginally useful on its own. To be truly useful, it is necessary to discern exactly what the error was in order to track it down and debug it. To this end, DBI defines several error diagnostic methods that can be invoked against any valid handle, driver, database, or statement. These methods will inform the programmer of the error code and report the verbose information from the last DBI method called. These are: $rv = $h->err(); $str = $h->errstr(); $str = $h->state(); These various methods return the following items of information that can be used for more accurate debugging of errors:
The error information for a handle is reset by the DBI before most DBI method calls. Therefore, it's important to check for errors from one method call before calling the next method on the same handle. If you need to refer to error information later you'll need to save it somewhere else yourself. A rewriting of the previous example to illustrate using the specific handle methods to report on errors can be seen in the following code:
#!/usr/bin/perl -w
#
# ch04/error/ex3: Small example using manual error checking which
# also uses handle-specific methods for reporting
# on the errors.
use DBI; # Load the DBI module
### Attributes to pass to DBI->connect() to disable automatic
### error checking
my %attr = (
PrintError => 0,
RaiseError => 0,
);
### Perform the connection using the Oracle driver
my $dbh = DBI->connect( "dbi:Oracle:archaeo", "username",
"password" , \%attr )
or die "Can't connect to database: ", $DBI::errstr, "\n";
### Prepare a SQL statement for execution
my $sth = $dbh->prepare( "SELECT * FROM megaliths" )
or die "Can't prepare SQL statement: ",
$dbh->errstr(), "\n";
### Execute the statement in the database
$sth->execute
or die "Can't execute SQL statement: ", $sth->errstr(),
"\n";
### Retrieve the returned rows of data
while ( my @row = $sth->fetchrow_array() ) {
print "Row: @row\n";
}
warn "Problem in fetchrow_array(): ", $sth->errstr(), "\n"
if $sth->err();
### Disconnect from the database
$dbh->disconnect
or warn "Failed to disconnect: ", $dbh->errstr(), "\n";
exit;
As you can see, it's even more long-winded than using the In addition to these three methods, which allow finely grained error checking at a handle level, there are three corresponding variables that will contain the same information, but at a DBI class level: $DBI::err $DBI::errstr $DBI::state Use of these variables is essentially the same as that of Since these variables are associated with the last handle used within the DBI, they have an even shorter lifespan than the handle error methods, and should be used only immediately after the method call that failed. Otherwise, it is highly likely they will contain misleading error information. The one case where the variables are very useful is for connection errors. When these errors occur, there's no new handle returned in which to hold error information. Since scripts don't use the internal driver handles, the In summary, for most applications, automatic error checking using |
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 