On Wed, Jul 7, 2010 at 8:37 AM, Graeme Geldenhuys <graemeg.li...@gmail.com> wrote: >> procedure TObj1.Free; >> begin >> Try >> Disk1.Unmount; >> Except >> On E:Exception do begin >> // Some case stuff here >> end; >> end; >> Inherited Destroy; >> end; >> > > With the exception of a possible memory leak in case Disk1.Unmount was > supposed to free up some resources. And if your app is something that > runs 24/7, that is a *huge* problem! Eventually you will run out of > memory and the whole thing will come crumbling down (and maybe even > cause more damage). >
Grame, no more caveats. If Unmount had memory that needed to be released then the same methodology stands. Disk1.Unmount was placed there to prove a point. That w/o handling Obj2.Free would never be called in context (the outstanding proposed example). As far as *HUGE* problem. Having to restart my server would be huge.. Especially in high scale, high available production environments. Having a handle in place that says CATCH STUFF HERE like Save to SQL server (if your needing to write to disk). The example I introduced is a good one. Ignoring the exception will indeed cause a fatal error. Handling the exception is the best practice here. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
