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

[Giuliano Colla]

On 02/11/2013 05:12 PM, Sven Barth wrote:
> 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).
>

I extracted from my code a minimal example, and I too can see the 
exception dialog, which doesn't show in the main application.

I don't see why the extra code should create a problem, but, by adding 
one piece after the other I should be able to find out where the problem 
comes from. However, replacing the original try..finally with a 
try..except, the main application behaves properly, but in that case 
it's the application which pops up the error dialog.

Giuliano