DBI error handling

[Tore Aursand]

You're not "thinking Perl" then. I find the RaiseError mechanism
to create much cleaner code. When enabled, I can do things like:

eval {
...;
...;
...;
...;
};
if ($@) {
# something went wrong with something in this section
}

whereas without RaiseError, I'm stuck setting status variables
and nesting if statements to get the same effect.

Really? Consider this code;

my $sth = $dbh->prepare( 'SELECT * FORM user' ); # typo 'FORM'
if ( $sth->execute() ) {
# Works!
}
else {
# Doesn't work!
}
$sth->finish();

I think this is cleaner, and I also suspect it to be faster than using
'eval'. Doesn't 'eval' spawn of a "mini-Perl" process, and doesn't it
take some time to run? Doesn't that hurt in a DB'ish application?

 

[Ben Morrow]

Really? Consider this code;

my $sth = $dbh->prepare( 'SELECT * FORM user' ); # typo 'FORM'
if ( $sth->execute() ) {
# Works!
}
else {
# Doesn't work!
}
$sth->finish();

I think this is cleaner, and I also suspect it to be faster than using
'eval'.

Whether or not it is cleaner depends on the application. Some
applications benefit from not having to check the return of every
statement, instead being able to put all the error handling in one
place.

Doesn't 'eval' spawn of a "mini-Perl" process, and doesn't it
take some time to run?

As someone else said, you are confusing eval "" with eval {}. Yes,
this is something of a conflation of ideas: the concept of catching
die() is quite different from run-time evaluation of code; but there
we go.

Ben