[fpc-pascal] TIniFile crash/memory loss

José Mejuto joshyfun at gmail.com
Fri Apr 1 09:44:52 CEST 2011


Hello FPC-Pascal,

Friday, April 1, 2011, 12:17:30 AM, you wrote:

B> The job of the destructor, however, is to clean up the object and return memory.
B> This should never fail IMHO.

The clean up has not been successfully performed as in this class a
file update is part of the clean up. There are other classes that may
fail in the free like ThreadList, TBinaryObjectWriter, and many others
that call user code in the destroy. IMHO the free should only raise an
exception in serious cases, and the main job of the class is not
performed.

B> One could even argue that the whole call to UpdateFile in the
B> destructor simply should not be there.

I agree.

B> If the user (programmer) takes the risk of caching the write updates,
B> then it is the programmers responsability to make sure the cached
B> values are written at some point.

Exactly so it must never update the file in the destroy.

B> Tipically I would do something like
B> begin
B>   try
B>     Ini := TIni.Create(AFilename);
B>     try
B>       Ini.CacheUpdates := True;
B>       Ini.WriteString(SomeSection, SomeIdent, SomeValue);
B>       //lots of writing
B>       Ini.UpdateFile; //flush bugger to file
B>     except
B>       ShowMessage('Unable to write to config file');
B>     end;
B>   finally
B>     Ini.Free;
B>   end;
B> end;
B> I would the expect that all (writing) errors are trapped, and the
B> finally statement ensures cleaning up.

If you write that code you will never get an exception in the free.

B> I have come to understand that Delphi does it in such a way.
B> If writing fails, the destructor is still (silently) done.

I do not know how Delphi does it :-?

-- 
Best regards,
 José




More information about the fpc-pascal mailing list