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

[Lukasz Sokol]

On 13/02/2013 09:39, Mark Morgan Lloyd wrote:
> Lukasz Sokol wrote:
> 
>> To developers: How would a generalized/packed construct like
>> 
>> try [code block] finally [code block] except [code block] end;
>> 
>> (in other words: a try-*-end construct where * can be 'finally', or
>> 'except', or BOTH.)
>> 
>> fit into Pascal philosophy? Advantages is mainly: - one less indent
>> level ('oh, I need try-except around all THAT, bugger.') to care
>> about; (yeah, even with all the good tools to manage the code, it
>> stings, that the two    have to be separately declared and one
>> needs to remember that...)
> 
> I think this complicates things unduly. As it is case-else and
> then-else are about the only places where there is this sort of
> composite block, and finally-except-end is even uglier since parts of
> all three blocks may be executed.
> 

With the traditional construct there could be another place that 
poses a potential pitfall:

[use fixed width font to see below comfortably]

try		vs	try
  try			  [...]
    [...]		finally
  finally		  [...]
    [...]		except
  end;			  [...]
  //(*1*)		end;
except 			
  [...]
end;

Using the composite one, protects the user of this construct from putting code into *1* place
where it may not be executed if exception happens in the try..finally block;

I'm not saying, this is not sometimes that one wants, but (at least in my case, YMMV)
putting code in *1 is a result of a thinko/PEBKAC. There, this I think is another (better?) 
argument in favor of composite try...finally...except...end;

I still think the latter (single-level, composite) is nice to have.
And acknowledges that the two are in effect used together most of the time.

And lets one to easily add a 'finally' or 'except' section if need arises, without
loosing any code to *1* black hole.

Regards,
Lukasz