Handling db errors within transactions

I have many DBI-based query sequences that look like this:

    *** begin transaction ***
    query #1:  select ...
    query #2:  update ...
    query #3:  select ...
    *** end transaction ***

If query #2 fails due to an exception (say, a duplicate key error), I can
identify that error **per query** via the DBI API, but then there appears
to be no possibility of even accessing the db again until/unless a
rollback is issued.  All subsequent queries result in the famous line

    NOTICE:  current transaction is aborted, queries ignored until end of
transaction block

I know this is an issue that has been discussed previously and a true fix
involves a ton of work that nobody really wants to do; I'm looking more
for workaround ideas.

One obvious (and very ugly) solution is to wrap every db access with
logic to catch errors and additionally then issue a rollback and begin a
new transaction to enable additional queries.  I like to find a cleaner
way to manage errors at a finer level of control granularity that still
enabled delegation of logic without major contortions.

Does anyone have any experience with a cleaner manner in which to handle
this issue?

Regards,
Ed Loehr