[fpc-pascal] Re: Fpc Access Violation if AppConfigDir doesn't exist.
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.
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;
(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,
More information about the fpc-pascal