[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.

Giuliano Colla giuliano.colla at fastwebnet.it
Mon Feb 11 00:13:00 CET 2013

On 02/10/2013 12:43 PM, Graeme Geldenhuys wrote:
> On 2013-02-09 13:56, Bart wrote:
>> While this can easily be implemented without breaking existing code,
>> this still does not solve the original problem.
>> If creating the directory fails, the function does not return an
>> errorcode, unless we decide to let it raise an exception in this
>> case..
> That's why I think they should stay as two separate prodecures.
Looking more carefully into the matter, the real inconsistency is not in 
GetAppConfigFile, or in GetAppConfigDir, which just do what they're 
meant for, but in TIniFile:

1) When you use it to *read* configuration parameters, if the file 
doesn't exist it silently just passes you the default values. This is 
normal, because the first time the program runs it didn't yet have the 
chance to write configuration data.

2) When you use it to *write* configuration parameters, it silently 
creates the file, and puts there the parameters. This again is normal, 
because the first time the program run the configuration file isn't 
there yet.

3) But if also the *path* to the file doesn't yet exist, it just crashes 
without rising an exception that the user application can handle somehow.

This is rather unpleasant, because the path provided by GetAppConfigXx 
does usually exist, so you have an application which 99% of the times 
works just fine, and 1% of the times crashes without telling why.

This was perhaps tolerable when GetAppPathConfigXx did not exist, and it 
was developer responsibility to provide a reasonable path, taking into 
account different target system, but today I'd expect TIniFile to take 
care also of forcing the appropriate path, and to raise an exception if 
it fails.


More information about the fpc-pascal mailing list