Automatic Versus Manual Error Checking
Early versions of the DBI required programmers to perform their own error checking, in a traditional way similar to the examples listed earlier for connecting to a database. Each method that returned some sort of status indicator as to its success or failure should have been followed by an error condition checking statement. This is an excellent, slightly C-esque way of programming, but it quickly gets to be tiresome, and the temptation to skip the error checking grows.
The DBI now has a far more straightforward error-handling capability
in the style of
exception
s.
That is, when DBI internally detects that an error has occurred after
a DBI method call, it can automatically
either
warn()
or
die()
with
an appropriate message. This shifts the onus of error checking away
from the programmer and onto DBI itself, which does the job in the
reliable and tireless way that you’d expect.
Manual error checking still has a place in some applications where failures are expected and common. For example, should a database connection attempt fail, your program can detect the error, sleep for five minutes, and automatically re-attempt a connection. With automatic error checking, your program will exit, telling you only that the connection attempt failed.
DBI allows mixing and matching of error-checking styles by allowing you to selectively enable and disable automatic error checking on a per-handle basis.