DBI error handling

T

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?
 
B

Ben Morrow

Tore Aursand said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top