Lukasz Sokol ha scritto:
It is subtle, I agree, but in
try
try
[code]
finally
[code]
end;
except
[code]
end; (my version)
I can catch the errors of either normal and finally code;
I assume that try...finally...end is the more important; it is try...finally..
end that has to go without errors,
or else one will be reported; if no exception happens, except is omitted; the
except section in this case, can
catch anything and its job is to decide whether to allow further execution,
show/log a message or bail out.
(also AFAICS this way it is recommended to be used in most snippets)
In your case (try..finally...end being the outer), what if it may not be possible to free the global resources
(e.g. if you .Created a TStringList, and in finally you want to .Free it, but say, its pointer got corrupted or
something free'd it already, and you can't - you'll get an AV which you'd have to catch in another try..except..end
to properly show user a message? Or if something else that has to be done in finally section, throws?)
The purpose of the try..except construct is to allow the developer to
put some remedy in case of errors, instead of just aborting the program.
The purpose of the try..finally construct is to guarantee some actions
even if the program is going to be aborted.
The new constructs would provide both options at the same time. But I'm
afraid that there's not a "better solution" good for all situation. It
depends on what one tries to do in the try.. clause, on which errors one
choses to deal with on the except clause, and the likelihood of
recoverable errors in the finally clause.
Allowing both constructs, (try..except..finally and
try..finally..except) as Sven suggested, would most likely cover a
broader range of cases.
Then, sometimes someone will still need nested try..whatever, to deal
with situations which do really require the HOLES you mentioned.
Giuliano
--
Giuliano Colla
Whenever people agree with me, I always feel I must be wrong (O. Wilde)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
