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

[Sven Barth]

On 13.02.2013 17:50, Giuliano Colla wrote:
>>> 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 don't see the point of a "else" or "nonexcept" branch. If I want code 
to be executed in the case that no exception happened (e.g. a Commit for 
a database transaction) then I put in the block started by the "try"... 
One might argue that an additional branch would increase readability, 
but I personally don't see a real use for it...

>>
>> 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!).

Application.Terminate is not special. It merely sets a "FTerminated" to 
True which will trigger a leave of the application main loop once the 
event handler returns. The only function that would be special in that 
regard is "Halt", but that already works that way that any handlers are 
skipped.

> 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.

Regards,
Sven