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.
Setting errstr and state to non-false values at the same time
has the slight risk that it'll affect code that uses $h->errstr
(or $DBI::errstr) to check for errors. But that's a slight risk.
If no one has a good objection I'll document this (err being 0
instead of undef and errstr and state being set) as the preferred
way to signal info/warning conditions.
Thanks!
Tim.
