Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Another Good Reason to use RaiseError

by grantm (Parson)
on Jun 19, 2002 at 12:08 UTC ( [id://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