At 18:09 +0000 2/7/02, Tim Bunce wrote: > =item C<ping> >*************** >*** 4181,4190 **** > situations to allow the server to free up resources (such as sort > buffers). > >! 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. (Adding calls to C<finish> after each >! fetch loop is a common mistake, don't do it, it can mask other problems.) > > Consider a query like: > >--- 4181,4194 ---- > situations to allow the server to free up resources (such as sort > buffers). > >! 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. - If you don't have RaiseError enabled, then you probably also would have an error test following the loop and before calling finish(). - 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. 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?
