>
> On Wed, Aug 21, 2002 at 09:59:23PM -0700, David Wheeler wrote:
> > Hi All,
> >
> > I'd like to submit a simple patch that causes the DBI connect() method
> > to execute a HandleError code reference if it has one. There's a
> > comment suggesting that it could be added, and it makes sense to me, so
> > I submit this patch.
> >
> > --- DBI.pm.org Wed Aug 21 21:09:27 2002
> > +++ DBI.pm Wed Aug 21 21:24:28 2002
> > @@ -503,7 +503,8 @@
> > unless ($dbh = $drh->$connect_meth($dsn, $user, $pass, $attr)) {
> > my $msg = "$class->connect($dsn) failed: ".$drh->errstr;
> > if (%attr) {
> > - # XXX add $attr{HandleError} logic here?
> > + # XXX add $attr{HandleError} logic here? Yes!
> > + $attr->{HandleError}($msg, $drh, $dbh) if
> > $attr->{HandleError};
> > Carp::croak($msg) if $attr->{RaiseError};
> > Carp::carp ($msg) if $attr->{PrintError};
> > }
> >
> > Yep, that's it!
>
> Thanks (and for the subsequent ones :)
>
> > Actually, there are a couple of other places in connect() where DBI
> > croaks() that don't take advantage of the HandleError attribute, but it
> > seems to me that it makes sense for it to. I'm thinking here of the
> > Usage error and the attempt to connect without specifying a database
> > driver. I understand that DBI has to croak at these points, but it also
> > seems to me that it could equally try executing a HandleError attribute
> > first. My thought is that, in those circumstances, DBI will pass in the
> > class name as the second argument, since there isn't yet a handle
> > object. I've attached a patch that implements that behavior, as well as
> > the behavior defined above. Thoughts?
>
> I'm comfortable with leaving those unchanged. I see them as preconditions.
> Anyone else got a view?
Not specifically, but maybe I'm missing something. If HandleError is
called, shouldn't the result of $attr->{HandleError} be checked before
trying to RaiseError or PrintError?
Jeff
