On Tue, Jan 13, 2004 at 02:28:40PM +0000, Tim Bunce wrote:
> On Tue, Jan 13, 2004 at 12:35:07PM +0100, Steffen Goeldner wrote:
> >
> > Tim Bunce wrote:
> >
> > > My current plan is to add a $h->{HandleEvent} = sub { ... }
> > > hook that can be used for SUCCESS_WITH_INFO and other events the
> > > driver may want to communicate back to an application.
> > >
> > > Meanwhile I suggest that you add a $h->{ado_event} = sub { ... }
> > > and and use that however you think best. Your experience can feed
> > > back into the HandleEvent design.
> >
> > O.k., but set_err() - how about that (for now)?
> > Should it be called or not? Or should it be called with
> > err == 0, which makes errstr and state accessible (if not
> > overwritten with the next error), but doesn't trigger the
> > normal DBI error handling mechanisms?
>
> Umm, yes, normally $h->err ($DBI::err) is undef. Setting it to
> 0 to indicate info or warning but not an error is a good idea.
I should add that the specific case of fetch returing SUCCESS_WITH_INFO
for 'no more rows' should not trigger this behaviour. There's no point.
I'm thinking in terms of adding a $h->{HandleWarn} callback that'll
be called by the DBI when it detects that err() has been set to 0.
Something like:
$h->{HandleWarn} = sub {
my ($errstr, $h, $state) = @_;
...
return ...; # new value for err()
};
It'll be called just before the existing RaiseError checks to it can
easily 'promote' a warning to an error.
Any comments?
Tim.
