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

[Sven Barth]

On 11.02.2013 13:18, Sven Barth wrote:
> Am 11.02.2013 13:06, schrieb Giuliano Colla:
>> Il 11/02/2013 12:35, Michael Van Canneyt ha scritto:
>>>
>>>
>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>
>>>> Il 11/02/2013 09:21, Michael Van Canneyt ha scritto:
>>>>>
>>>>>
>>>>> On Mon, 11 Feb 2013, Giuliano Colla wrote:
>>>>>
>>>>>> 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 incorrect. It does tell you why it fails.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> It tells you *exactly* why it 'crashes':
>>>>>
>>>>> home: >./ti
>>>>> An unhandled exception occurred at $000000000042AE87:
>>>>> EFCreateError: Unable to create file "/tmp/path/to/nothing.txt"
>>>>>   $000000000042AE87
>>>>>
>>>>
>>>> This is true only if you invoke the program from command line, which
>>>> is something the end user will never do.
>>>
>>> That is not the problem of TIniFile, but of the application programmer.
>>>
>>> TIniFile properly reports any error, as it should, with an exception.
>>> It is always up to the application programmer to deal with such cases.
>>>
>>> That this is sometimes tricky in a GUI application, cannot be helped.
>>>
>>
>> It can be helped both by reducing the likelihood of the event, as
>> you've done, and by not suggesting to use in that case a try..finally
>> construct in a GUI application, which would mask the errors.
> The "try..finally" itself will not mask the error. The error will
> propagate to the next surrounding "try..except" handler (executing the
> code in all finally sections it encounters) and normally this will
> result in a dialog being displayed (if you did not change
> Application.OnException). It could be however that you try to create the
> configuration file when the usage of GUI is no longer possible (I don't
> know).

Just to prove my point: I wrote the following little test program in 
Lazarus. Add a button to a empty form and assign the OnCreate and 
OnDestroy events of the form and the OnClick event of the button and add 
the following code to them:

=== snippet begin ===


procedure TForm1.FormCreate(Sender: TObject);
begin
   try
     raise Exception.Create('FormCreate');
   finally
     MessageDlg('FormCreate Finally', mtInformation, [mbOK], 0);
   end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
   try
     raise Exception.Create('Button1Click');
   finally
     MessageDlg('Button1Click Finally', mtInformation, [mbOK], 0);
   end;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
   try
     raise Exception.Create('FormDestroy');
   finally
     MessageDlg('FormDestroy Finally', mtInformation, [mbOK], 0);
   end;
end;

=== snippet end ===

If you now run the application (for now I assume you run it without a 
debugger or outside the IDE) you first get the "FormCreate Finally" 
dialog, then a "Exception "FormCreate" occured" dialog and then the form 
will be display. An analogous event will happen if you click the button 
and as well when you close the form.

So it would be nice if you'd show where exactly no error message is 
displayed for you (preferrably with a compiling code example).

Regards,
Sven