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

[Lukasz Sokol]

On 13/02/2013 16:50, Giuliano Colla wrote:

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

It is subtle, I agree, but in

try
  try
  [code]
  finally
  [code]
  end;
except
[code]
end; (my version)

I can catch the errors of either normal and finally code;
I assume that try...finally...end is the more important; it is try...finally.. end that has to go without errors,
or else one will be reported; if no exception happens, except is omitted; the except section in this case, can
catch anything and its job is to decide whether to allow further execution, show/log a message or bail out.
(also AFAICS this way it is recommended to be used in most snippets)

In your case (try..finally...end being the outer), what if it may not be possible to free the global resources 
(e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or 
something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end
to properly show user a message? Or if something else that has to be done in finally section, throws?) 

Kind Regards,
Lukasz