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 _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
