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

Lukasz Sokol el.es.cr at gmail.com
Wed Feb 13 10:11:32 CET 2013


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;

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

Would it be very complicated? 

Lukasz




More information about the fpc-pascal mailing list