On Thu, Jan 15, 2004 at 03:37:20PM +0000, Tim Bunce wrote:
> 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?
The RaiseError/PrintError/HandleError mechanism only applies at the
point where the DBI is abount to return control to the application.
It isn't triggered by a "nested" calls (where select*_* calls prepare())
I was planning to implement HandleWarn the same way but
I've realised that "undef error before most method calls" mechanism
would often clear the warning state before higher level method returns.
Consider:
sub do {
my($dbh, $statement, $attr, @params) = @_;
my $sth = $dbh->prepare($statement, $attr) or return undef;
$sth->execute(@params) or return undef;
my $rows = $sth->rows;
($rows == 0) ? "0E0" : $rows;
}
a warning from prepare would be lost by calling execute.
So I thought I might change the "undef error before most method
calls" mechanism to only undef it if it's currently true (there was
an error). That way the 'warn' state would persist until the next error
(possibly a long time).
But I wasn't happy with that as I'd want to know about info/warning
states ASAP and so be able to promote them to an error ASAP.
So now I'm implementing HandleWarn so warnings will be checked for
when whenever a method returns, even nested calls. [Strictly speaking
it'll only apply to same method calls that the "undef error before call"
mechanism applies to - but that's most of them.]
Tim.
