laziness, impatience, and hubris | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Um, no. If $dbh ever becomes 0 in that two lines, something very unexpected has happened in perl, i.e. you have triggered a serious bug and/or corrupted memory. (Or you simply have redefined die to return 0 instead of dieing.) Yes, I'm bean counting again. Sorry. First, DBI->connect() is documented to return undef on error, a database handle object if the connection succeeds. It should never return 0 at all, or anything else than undef or a blessed reference (i.e. an object). Second, 0 and undef are two very different values, and while they are treated the same on the left-hand side of or (as a boolean FALSE value), they are not generally exchangeable. Side note: Around DBI, there is also the special zero value 0E0 that is treated by perl as a boolean TRUE value, returned by execute() and similar methods (do(), execute_array(), execute_for_fetch()) to indicate success with zero rows affected. Some of the core functions (fcntl, ioctl, msgctl, semctl, shmctl, sysseek) return the special value 0 but true for a very similar purpose. That special value is excempt from warning complaints about improper numeric conversions (documented in ioctl). Third, should DBI->connect() return undef, 0 or any other value that evaluates to FALSE in boolean context, the right-hand side of or will be executed and die will prevent any assignment to $dbh by either exiting the interpreter or by jumping out of a surrounding eval block. So, $dbh starts unassigned, but will never be assigned 0 (unless you have redefined die to return 0). Alexander
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-) In reply to Re^2: Perl Not returning SQL query result
by afoken
|
|