[moved from dbi-dev to dbi-users] On Fri, Feb 08, 2002 at 11:56:25AM -0600, Paul DuBois wrote: > > >! When all the data has been fetched from a C<SELECT> statement, the > >! driver should automatically call C<finish> for you. So you should > >! I<not> normally need to call it explicitly I<except> when you know > >! that you've not fetched all the data from a statement handle. > >! The most common example is when you only want to fetch one row, > >! but in that case the C<selectrow_*> methods may be better anyway. > >! Adding calls to C<finish> after each fetch loop is a common mistake, > >! don't do it, it can mask genuine problems like uncaught fetch errors. > > Granted that finish() after a loop is unnecessary(). But how does it > mask problems? > > - If RaiseError is enabled, a fetch error raises an exception anyway.
Sure. Yet another case for using RaiseError. > - If you don't have RaiseError enabled, then you probably also would > have an error test following the loop and before calling finish(). But almost no one does. > - If you don't have RaiseError enabled, and you have no test after > the loop prior to the finish() call, you weren't going to find the > error anyway. In that case you'd get the "active statement handle destroyed" warning. > What's an example where having finish() after the loop actually makes > a difference? I'm trying to understand why is it a "mistake", as > opposed to simply being superfluous? Consider doing a select returning many rows some of which are either a) LONGs where one row has a length>LongReadLen and LongTruncOk=0 or b) fields calculated like "foo/bar" where a row has bar=0 The application is merrily calling fetchrow_*() in a while loop. When it reaches the bad row the fetch will fail. Without RaiseError and with no error check after the loop the only way you'll notice the premature end of fetching is by the warning. But you won't get the warning if you've called finish(). Assuming that's clear... would you like to propose a change to the new docs that'll clarify the issue? Tim.
