On Thu, Jan 15, 2004 at 12:04:47PM -0000, Avis, Ed wrote:
> Tim Bunce wrote:
> 
> >>>A statement handle should always have NAME, TYPE, NULLABLE etc
> >>>attributes.  It should never be an error to ask for them. But the
> >>>value returned may be undef, for example, if the statement 
> >>>has not been executed, the execute failed, or it's not a select
> >>>statement.
> >> 
> >>If RaiseError is set, then shouldn't accessing one of these 
> >>when it is not available throw an exception rather than giving undef?
> >
> >I don't think so. It's not an error, it's just unavailable
> >(although you could argue it either way).
> 
> You give a long list of possible reasons why the data could be
> unavailable, quoted above.  Undef could mean any of those and it's not
> possible to find out which.  An exception can say what the problem is.
> 
> You'd get questions from beginners saying 'I get $sth->{NAME} but it is
> always undef, what am I doing wrong?'.  The answer is probably that you
> need to execute() first.  An error message would make this obvious.
> 
> Or consider porting a program from one DBD driver to another.  The
> original driver made {NAME} available before executing, but the new one
> does not.  It would be better to see an obvious failure rather than have
> the program get undef and go wrong later.
> 
> You can of course write your code to always check that an attribute is
> defined after fetching it.  But the point of RaiseError is that you
> don't have to type these explicit checks after every DBI operation.

I've remembered the deeper issue here...

FETCH is marked as a 'keep_error' method. That means that err & errstr
are not cleared before the call and not checked (for RaiseError etc)
after it.

I'm reluctant to change that as any code that fetches an attribute
after a method call but before checking $h->err (or $DBI::err) will
now not see the error.

For DBI v2 I'll look into adding a mechanism to let some methods
only check for 'new' errors.

Then, for the example above, the old err will only be 'lost' if it's
replaced by a new one. (And DBI 1.41 will ensure the old errstr text is
appended to rather than overwritten.)

Tim.

Reply via email to