From:	Steven Lembark	Date:	Tue Jan 24 14:27:46 2006
Subject:	Error recovery mechanism

DBI-1.50 uses a technique with HandleError that allows the 
handler to update or zero the error message and insert any
data it wants to into the return. The HandleError sub
can currently return false to indicate that DBI should
follow the normal error procedure or true to just return
the update data content and ignore the error.

The main problem with this approach is that even in cases
where the handler can deal with the error (e.g., reconnecting
the database handle) it is difficult to redispatch the 
original request. The handler can put a sentinel value into
the returned data to indicate that the caller should re-
attempt the DBI operation, but this is messy at best.

There is also the limitation that even where the handler
can fix the problem, it can only return one value, which
leaves it unable to resolve fetch*_array and fetch*_hash
calls by itself.

A better approach might be allowing the error handler
to signal DBI that it should re-dispatch the original
request and return the result. This could be signalled
via three-state logic in the ErrorHandler's return 
value or exporting a "redispatch" method that the 
handler could use for itself.

Tristate logic would use undef, false, or true to 
distinguish between reporting the error, ignoring
the error without redispatch (what true does now),
or redispatching the request (not avaiable now).
The main downside to this method of handling things
is the possibility for infinte loops of partially-
handled errors re-entering the ErrorHandler (a
counter in the handler should make this easy enough
to deal with ).

The redispatch method would require some additional
bookkeeping on DBI's part: storing the last method
and its arguments. Some of this is already done 
in DBI-1.50 and the amount of it is small enough 
that it should not be a major problem.

In this case the fixup handler could fix the problem
(say, re-connecting a new handle and replaceing the
existing one with the new one) then call:

    $dbh->redispatch;

to replay whatever caused the error. 

Becuase this would be done within the fixup handler,
it could more easily avoid infinte loops (by croaking
if it gets back an error from the re-dispatch) or 
signal true to have the redispatched values handed 
back to the caller.

A small change in the handling of the input arguments
would simplify this also. In DBI-1.50, the HandleError
sub gets a single value to play with. If this were an
arrayref then the fixup handlers could replace them
with the full return value handed back to the caller.
An alternative would be passing in a scalar ref which
could then be updated with whatever the handler wants
returned, it could then be de-referenced in the DBI
error layer to get a return.

These could easily be combined in the DBI error
handler with something like:

    # dbi layer calls handler

    # syntatic sugar. call order looks more like
    # what OO people expect: the object first.

    my $handler     = $dbi->{HandleError};

    if( my $user_data = $dbh->$handler( $message, $user_data ) )
    {
        # caller gets the expanded return value back,
        # which allows for passing anything back.

        @$user_data;
    }
    elsif( defined $a )
    {
        # redispatch the original call with its original 
        # arguments.

        $dbh->redispatch;
    }
    else
    {
        # continue as usual

        die;
    }




-- 
Steven Lembark                                       85-09 90th Street
Workhorse Computing                                Woodhaven, NY 11421
lembark@wrkhors.com                                     1 888 359 3508