On 13.02.2013 17:50, Giuliano Colla wrote:
Python provides the following:
try
[code block]
except
[code block]
else
[code block]
finally
[code block]
end;
which can be used in any reasonable combination: just try..except,
just try..finally just try..except..else etc.
The except..else is a very useful construct, because it provides a
path to a code block to execute only if there were no previous errors.
This wouldn't break any existing applications, just add very useful
features.
What fpc developers think about that?
"Else" is used in Except already to select between various classes:
try
..
except
on E : MyType do
begin
end
else
// exception is not MyType
end;
so that is a problem.
I didn't think of that, because I never use it. It would be nice to use
it the other way, but I understand it would break existing code. A
different keyword like nonexcept?
I don't see the point of a "else" or "nonexcept" branch. If I want code
to be executed in the case that no exception happened (e.g. a Commit for
a database transaction) then I put in the block started by the "try"...
One might argue that an additional branch would increase readability,
but I personally don't see a real use for it...
I see no problem in adding finally, if you define carefully when it is
executed.
IMHO the try..except..finally construct should provide exactly the same
functionality as a nested
try
try
[code]
except
[code]
end;
finally
[code]
end;
i.e. it should be executed whatever happened in the sections between try
and finally (except if somewhere there was an Application.terminate!).
Application.Terminate is not special. It merely sets a "FTerminated" to
True which will trigger a leave of the application main loop once the
event handler returns. The only function that would be special in that
regard is "Halt", but that already works that way that any handlers are
skipped.
Any exception not handled shoud be re-raised after the finally block has
been executed.
The advantage would be to get rid of one level of nesting, making the
code more readable and less error prone.
This would guarantee both proper error handling and freeing of global
resources, even in presence of errors.
Regards,
Sven
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
