http://qs321.pair.com?node_id=535142


in reply to Catching DBI (or other) errors

You could write it as

$query->execute() or do { $SQL_FAIL = 1};
But for a single line statement, you really don't need the braces, just :
$query->execute() or $SQL_FAIL = 1;
But why are you doing it this way?

This means that you then have to check the value of SQL_FAIL every line before processing the next statement.

Wrapping it all in an eval and using RaiseError really works a treat, looks clean makes your life simpler.

If you are using the value of SQL_FAIL to figure out what statement failed, then you could go the other way and have $sql_stage (note, not all in capitals because this implies a constant, which it isn't) and you could just set $sql_stage to the current stage you're working on. As in
my $sql_stage=1; eval { $query->execute(); $sql_stage = 2; $query2->execute(); $sql_stage = 3; $query3->execute(); }; if ($@) { if ($sql_stage < 3) { $fix1->execute(); } else { $fix2->execute(); } }

Replies are listed 'Best First'.
Re^2: Catching DBI (or other) errors
by duckyd (Hermit) on Mar 08, 2006 at 16:32 UTC
    If I were going to do something like this, I'd probably do something more like:
    $query->execute and $sql_stage++; $query2->execute and $sql_stage++;
    etc.

      That would execute all queries even if one of them failed though. And if after your code finishes, $sql_stage is 1, you still don't know whether it was $query or $query2 that failed. Now add 3 or 4 more queries to that list and the $sql_stage variable becomes practically useless for anything except comparing to the total number of queries.

        But wrapped in an eval and combined with RaiseError, it would stop counting at the point where your query goes wrong.

        It is a bit annoying in that you have to count your queries to know which went wrong, but there may be one or two specific action points: if queries 1-4 succeeded, but 5-8 failed do X, otherwise do Y.