On 3/31/11, José Mejuto <joshy...@gmail.com> wrote:
> B> This however means that the programmer has to protect TIniFile.Free
> B> with a Try..Except block, which is also rather unusual.
>
> It's unusual, but there is an error, or the class does not perform the
> save in the free procedure and uses a "flush" (forced) or the class
> must raise an exception as the expected job has not been performed.
The job of the destructor, however, is to clean up the object and return memory.
This should never fail IMHO.
One could even argue that the whole call to UpdateFile in the
destructor simply should not be there.
If the user (programmer) takes the risk of caching the write updates,
then it is the programmers responsability to make sure the cached
values are written at some point.
Tipically I would do something like
begin
try
Ini := TIni.Create(AFilename);
try
Ini.CacheUpdates := True;
Ini.WriteString(SomeSection, SomeIdent, SomeValue);
//lots of writing
Ini.UpdateFile; //flush bugger to file
except
ShowMessage('Unable to write to config file');
end;
finally
Ini.Free;
end;
end;
I would the expect that all (writing) errors are trapped, and the
finally statement ensures cleaning up.
I have come to understand that Delphi does it in such a way.
If writing fails, the destructor is still (silently) done.
Bart
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
