Lukasz Sokol ha scritto:
On 13/02/2013 13:14, Michael Van Canneyt wrote:
I'd rephrase what I discussed with Sven Barth:
this construct (the packed try.(1).finally.(2).except.(3).end;) - a
packed/condensed version -
I would be in favor of try..except..finally, as opposed to
try..finally..except, because I believe it better to handle exceptions
before, and clean-up after. Exception handling doesn't consist only in
showing an error box, it may involve also providing a remedy to some
errors, and hopefully passing to finally a cleaner situation to handle.
I'm ready to change advise if proved wrong.
- 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.
If one is left free not to use the new construct, he can use the old
one, and put in as many holes as he want.
After all one is free to insert anywhere in the code a few assembler
lines and to break anything fpc developers had in mind..
Giuliano
--
Giuliano Colla
Before activating the tongue, make sure that the brain is connected
(anonymous)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
