eval{} is a general solition but is not needed in this case becaue DBI handles have two modes for reporting errors depending on the state of the RaiseError attribute.

If $dbh->{RaiseError} is false (the default) then you can ignore SQL errors simply by not checking to see if there's been one.

Personsally I always open DBI handles with RaiseError true and switch it off locally in blocks where I want to ignore or recover from SQL errors.

To drop an SQL object that may or may not exist I do:

{
    local $dbh->{RaiseError} = 0;
    $dbh->do("drop table DSR_SMR_Result_storage_keep");
}
[download]

Obviously if the drop fails for some reason other than the object not existing then I miss the reason but since the next SQL statment is typically about to create the object again I do at least get an error there.

There used to be a memory leak when you used local on an element of a tied hash, and a DBI handle is a tied hash. See Memory Leak Bug. I don't know what Perl version it got fixed, if it even got fixed, but in case you're forced to use an old perl version like 5.005_03 or 5.6.0, then it's safer to use eval.

We're talking about a quick fix for a short piece of code that shouldn't be run too often. In such a case, I'm willing to settle for "easy" and "good enough" code. local is easy, emulating local to avoid the meory leak, isn't.