Michael Van Canneyt ha scritto:
On Wed, 13 Feb 2013, Giuliano Colla wrote:
Sven Barth ha scritto:
On 13.02.2013 10:11, Lukasz Sokol wrote:
On 13/02/2013 07:34, Michael Müller wrote:
I'm not sure if somebody else mentioned this already but I have the
feeling that Giuliano thinks that he has to decide to use
try-finally OR try-except but there are situations where you need
both. One of the criteria is if the object is local or global since
for a global object it is likely that you place the .Free (or for a
global object better FreeAndNil()) into a destructor or
finalization section (which means that you have to stop the program
in case of an error and not continue showing just a dialog) so
you'll need only the try-except if you want to catch the exception.
In case of a local object you'll ALWAYS have the lines
Obj := Class.Create;
try
// do some code
finally
Obj.Free;
end;
otherwise you'll end up with memory leaks.
If you want to catch the exception in this situation you'll put
try-except extra around try-finally so you'll end up with
Obj := Class.Create;
try
try
// do some code
finally
Obj.Free;
end;
except
writeln('We have a problem);
halt the program or reraise the exception or raise a new one
end;
Regards
To developers:
How would a generalized/packed construct like
try
[code block]
finally
[code block]
except
[code block]
end;
or what about
try
[code block]
except
[code block]
finally
[code block]
end;
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 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!).
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.
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
