On 14/02/2013 13:58, Giuliano Colla wrote:
> 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.
At first I thought, that having 2 versions of this construct, would be
overkill; and whether it is intuitive enough for everybody that the last
section will be the 'outside', it's hard to say without others input;
For myself, the more intuitive construct is, to do try, then finally,
if no exception anywhere then skip except, otherwise (whether it happened
in try or finally) execute the exception handling code. Which equals the tandem
construct with except on outside.
But now, I think it actually would be a good thing to have the other too;
Whether the order of the inside/outside sections should be selectable by order
of
keywords in the flattened construct, is still debatable; I think if majority
agrees that this is intuitive enough,
Main reason is to close the HOLEs, secondary, flatten the code and shorten it
down
even if only a bit.
Maybe he one and true answer for all of the above would be to have:
try vs try
try except
try finally
except except
end; end;
finally
end;
except
end;
so with except being optionally allowed either side of 'finally' ?
Lukasz
>
> Giuliano
>
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
