Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Another Good Reason to use RaiseError

by grantm (Parson)
on Jun 19, 2002 at 12:08 UTC ( #175636=note: print w/replies, xml ) Need Help??

in reply to Tricks with DBI

btrott mentioned that RaiseError is the recommended way to check for errors but that you could alternatively check the error return value for each DBI method call. Here's subtle case where not using RaiseError can bite you:

while ($sth->fetch) { print join("\t", $id, $name, $phone), "\n"; }

On the face of it, this will repeatedly call fetch until there is nothing more to fetch. In fact, fetch will return undef either when all rows have been fetched or when there was an error. Here's a couple of cases where fetch might successfully return a number of rows then return undef for an error:

  • you selected a calculated value (eg: total/count) which caused a divide by zero error
  • one of your columns is a long text field that exceeds the default buffer size (LongReadLen) and because you left the LongTruncOK option at default, it throws an error

In each case, you might see some output and mistakenly believe you'd seen all matching rows. The moral - always set RaiseError and wrap DBI calls using eval

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://175636]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2021-10-25 15:03 GMT
Find Nodes?
    Voting Booth?
    My first memorable Perl project was:

    Results (89 votes). Check out past polls.