Re: $sth->{NAME} doesn't work

From: Tim Bunce (Tim.Bunce_at_pobox.com)
Date: 01/27/04

  • Next message: Thomas A. Lowery: "Re: table editing application" 
    Date: Tue, 27 Jan 2004 22:42:32 +0000
To: "Avis, Ed" <avised@kbcfp.com>

    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.

  • Next message: Thomas A. Lowery: "Re: table editing application"

    Relevant Pages