in reply to DBI error and $@

I'm not entirely sure why the eval() is breaking, but $@ is not the variable you are looking for. That's because $@ contains what goes wrong inside an eval(), whereas DBI->errstr() will tell you what went wrong with the database.
HTH

broquaint

Update: I believe that $@ is dependent on the DBI driver you're using, so it's probably best not to rely on it as a means of communicating what went wrong.

Replies are listed 'Best First'.
Re: Re: DBI error and $@
by notsoevil (Pilgrim) on Dec 06, 2001 at 21:36 UTC
    This related to Transactions (or this is my intent). According to the 'Perl DBI' book (section 6.3.5 Combining Automatic Error Handling with Transactions):
    Imagine combining the automatic error detection of the DBI's RaiseError attribute and the error trapping of Perl's eval { ... } and the error handling properties of transactions. The result is a simple yet powerful way to write robust applications in Perl.
    ...
    Using RaiseError helps here because it generates a message (or Perl $@ variable value) that includes the underlying error from the driver, and the driver and method names.
    If $@ is not containing the error message, why does the example from the book (and Randal's article) use this method of trapping errors?

    --
    notsoevil
    --
    Jeremiah 49:32 - And their camels shall be a booty. . .

[reply]

      I believe you have misunderstood the advice: you combine the approaches, you don't replace one with the other.

      You have to set $@ yourself by calling die in the normal way:

      eval {
    $db->do($sql) or die $db->errstr();
    $db->commit();
}

if ($@) {
    warn "DB error: $@\n";
}

      [download]
[reply]
[d/l]
[select]
        I believe this is what the RaiseError argument is designed to do: check to be sure each DBI call succeeds, or die.
[reply]
[d/l]

      In addition to what the anonymous monk has to say (I'll admit it, it was me, not logged in), take a look at the code that creates the DB handle in that example, where RaiseError is set to 1 (i.e. true). That means the die is automatically called on a DB error, so it's functionally equivalent to the code "AM" provided.

      HTH

      I mistrust all systematizers and avoid them. The will to a system shows a lack of integrity -- F. Nietzsche

[reply]
[d/l]
        I have RaiseError set to 1 so like you say, die is called automatically, which should set $@. Is that incorrect? If so, why do the examples not use a explicit die statement with the errstr method -- they, from what I can tell, are just using $@ .. the errstr method is not used at all.

        --
        notsoevil
        --
        Jeremiah 49:32 - And their camels shall be a booty. . .

[reply]

In Section Seekers of Perl Wisdom