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

Lukasz Sokol el.es.cr at gmail.com
Wed Feb 13 16:23:56 CET 2013


On 13/02/2013 13:14, Michael Van Canneyt wrote:
> 

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

I second that, we don't need no pythonisms here ;) (or is it pythonosis?)

I'd rephrase what I discussed with Sven Barth: 

this construct (the packed try.(1).finally.(2).except.(3).end;) - a packed/condensed version -

- should be semantically EXACT to try.(HOLE1).try.(1).finally.(2).end;.(HOLE2).except.(3).end;

  Legend:
  (1,2,3): code blocks
  (HOLE1) possibility for the try..finally..end block to be skipped if exception happens here
  (HOLE2) possibility for code to be skipped if exception happens in the try...finally...end; block

- except, it will not have the HOLEs. Because [maybe some statistics needed here] this is 
probably the main (most advocated ?) use of them both at the same time.

- It shall allow any constructs that are allowed in traditional (1,2,3) code blocks to be 
used exactly the same way with the same meaning.

The new way will:

-flatten the source code (one indent level less)
-shorten the source code (one 'try' and one 'end;' less)
-provide automatic protection from falling into the (HOLEs). (thinkos and PEBKACs protection) 
 (this is most important here I think).

Note that I'm not advocating for this to replace the traditional constructs; 
Also I accept, that HOLEs may be perfectly justified code. But if someone needs them, they probably
know what they are doing.

Hope this makes sense,
Lukasz





More information about the fpc-pascal mailing list