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

[Giuliano Colla]

Michael Van Canneyt ha scritto:
> 
> 
> On Wed, 13 Feb 2013, Giuliano Colla wrote:
> 
>> Sven Barth ha scritto:
>>> On 13.02.2013 10:11, Lukasz Sokol wrote:
>>>> On 13/02/2013 07:34, Michael Müller wrote:
>>>>
>>>>> I'm not sure if somebody else mentioned this already but I have the 
>>>>> feeling that Giuliano thinks that he has to decide to use 
>>>>> try-finally OR try-except but there are situations where you need 
>>>>> both. One of the criteria is if the object is local or global since 
>>>>> for a global object it is likely that you place the .Free (or for a 
>>>>> global object better FreeAndNil()) into a destructor or 
>>>>> finalization section (which means that you have to stop the program 
>>>>> in case of an error and not continue showing just a dialog) so 
>>>>> you'll need only the try-except if you want to catch the exception. 
>>>>> In case of a local object you'll ALWAYS have the lines
>>>>>
>>>>> Obj := Class.Create;
>>>>> try
>>>>>    // do some code
>>>>> finally
>>>>>    Obj.Free;
>>>>> end;
>>>>>
>>>>> otherwise you'll end up with memory leaks.
>>>>> If you want to catch the exception in this situation you'll put 
>>>>> try-except extra around try-finally so you'll end up with
>>>>>
>>>>> Obj := Class.Create;
>>>>> try
>>>>>    try
>>>>>      // do some code
>>>>>    finally
>>>>>      Obj.Free;
>>>>>    end;
>>>>> except
>>>>>    writeln('We have a problem);
>>>>>    halt the program or reraise the exception or raise a new one
>>>>> end;
>>>>>
>>>>> Regards
>>>>>
>>>> To developers:
>>>> How would a generalized/packed construct like
>>>>
>>>> try
>>>> [code block]
>>>> finally
>>>> [code block]
>>>> except
>>>> [code block]
>>>> end;
>>>
>>> or what about
>>>
>>> try
>>> [code block]
>>> except
>>> [code block]
>>> finally
>>> [code block]
>>> end;
>>>
>>
>> Python provides the following:
>> try
>> [code block]
>> except
>> [code block]
>> else
>> [code block]
>> finally
>> [code block]
>> end;
>>
>> which can be used in any reasonable combination: just try..except, 
>> just try..finally just try..except..else etc.
>>
>> The except..else is a very useful construct, because it provides a 
>> path to a code block to execute only if there were no previous errors.
>> This wouldn't break any existing applications, just add very useful 
>> features.
>>
>> What fpc developers think about that?
> 
> "Else" is used in Except already to select between various classes:
> 
> try
>   ..
> except
>   on E : MyType do
>     begin
>     end
> else
>   // exception is not MyType
> end;
> 
> so that is a problem.

I didn't think of that, because I never use it. It would be nice to use 
it the other way, but I understand it would break existing code. A 
different keyword like nonexcept?

> 
> I see no problem in adding finally, if you define carefully when it is 
> executed.

IMHO the try..except..finally construct should provide exactly the same 
functionality as a nested
try
   try
   [code]
   except
   [code]
   end;
finally
[code]
end;

i.e. it should be executed whatever happened in the sections between try 
and finally (except if somewhere there was an Application.terminate!). 
Any exception not handled shoud be re-raised after the finally block has 
been executed.
The advantage would be to get rid of one level of nesting, making the 
code more readable and less error prone.
This would guarantee both proper error handling and freeing of global 
resources, even in presence of errors.

Giuliano

-- 
Giuliano Colla

Before activating the tongue, make sure that the brain is connected 
(anonymous)