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.
>
> 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.
Done.
=item C<err>
...
The DBI resets $h->err to undef before most DBI method calls, so the
-value only has a short lifespan. Also, most drivers share the same
-error variables across all their handles, so calling a method on
-one handle will typically reset the error on all the other handles
-that are children of that driver.
+value only has a short lifespan. Also, for most drivers, the statement
+handles share the same error variable as the parent database handle,
+so calling a method on one handle may reset the error on the
+related handles.
If you need to test for individual errors I<and> have your program be
portable to different database engines, then you'll need to determine
what the corresponding error codes are for all those engines and test for
all of them.
+Drivers may return C<0> (false but not undef) from err() to indicate
+a 'success with information' or warning condition after a method
+call. In this case the errstr() and/or state() methods may be used
+to retieve extra information.
+
=item C<errstr>
...
+The errstr() method should not be used to test for errors, use err()
+for that, because drivers may return 'success with information' or
+warning messages via errstr() for methods that have not 'failed'.
+
=item C<state>
...
+The state() method should not be used to test for errors, use err()
+for that, because drivers may return a 'success with information' or
+warning state code via errstr() for methods that have not 'failed'.
+
Tim.
