$drh Access

[David Wheeler]

This looks long, but the question at the end is really quite simple.

On Monday, November 25, 2002, at 03:56  PM, David Wheeler wrote:

(And should there be a section for $drh objects, BTW?).

Using a $drh directly is discouraged (partly because it's likely
to break if you use the proxy).

Ah, crap. Is a $drh object passed to any HandleError subrefs, yet? Wait, that's what my last patch does, isn't it? Exception::Class::DBI is getting a bunch of info from the handle passed to it -- all of the attributes that are "common to all handles". Is this wrong, then?

Tim, just to follow up on this question, I'd like to point out that the patch you applied and released as part of 1.31 actually now passes a $drh to an exception handler, which means that client code can now access the $drh object:

unless ($attr->{HandleError} && $attr->{HandleError}->($msg, $drh, $dbh)) {
Carp::croak($msg) if $attr->{RaiseError};
Carp::carp ($msg) if $attr->{PrintError};
}

So, I have code like this in Exception::Class::DBI (where the class of "$dbh" is assumed to be any one of the DBI handles):

my @params = ( error => $err,
errstr => $dbh->errstr,
err => $dbh->err,
state => $dbh->state,
retval => $retval,
warn => $dbh->{Warn},
active => $dbh->{Active},
kids => $dbh->{Kids},
active_kids => $dbh->{ActiveKids},
compat_mode => $dbh->{CompatMode},
inactive_destroy => $dbh->{InactiveDestroy},
trace_level => $dbh->{TraceLevel},
fetch_hash_key_name => $dbh->{FetchHashKeyName},
chop_blanks => $dbh->{ChopBlanks},
long_read_len => $dbh->{LongReadLen},
long_trunc_ok => $dbh->{LongTruncOk},
taint => $dbh->{Taint},
);

Since all of those attributes are documented to apply to all DBI handles, including driver handles, if "Using a $drh directly is discouraged", then how should I go about getting at those attributes from within my HandleError sub?

Thanks,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]