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.
Giuliano
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
