Jürgen Hestermann schrieb:
Am 2013-06-28 22:34, schrieb Bart:
> On 6/28/13, Junior <[email protected]> wrote:
>> strList.TStringList.Create;
>> try
>> if Pos('blablabla',strList.Text) = 0 then
>> Exit;
>> finally
>> strList.Free;
>> end;
>> Adding "Exit", the finally is executed?
> Just wondering. Why couldn't you test that yourself?
Is that the way programming is done today: "There is no documentation,
just figure it out yourself"?
I can't believe it.
Such documentation exists in most cases, but it may be hard to find, in
detail in a Wiki :-(
How can the programmer be sure that test results apply under all
circumstances?
Depends on the test code and results ;-)
Does he have to write test routines for all possible szenarious?
At least for all scenarios where the user doesn't trust the
documentation or answers to his questions. Sometimes very special code
can reveal compiler bugs, when the program does not behave as it should.
What about nested try..finaly commands?
Think of every try-finally block as a room, with one entry and one exit
door. Whenever the try block is left, execution must pass through its
exit door (finally block). Only after exiting from all rooms, floors
etc. this way, the subroutine is finally left (at its "end;").
Not so obvious: code *after* the finally-end is *not* executed after an
"exit;"!
procedure TestExit;
begin
try
WriteLn('enter try-finally block');
exit;
finally
WriteLn('reached finally');
end;
WriteLn('compiler error: this should never be reached!');
end;
Is it guaranteed that all finally parts are executed?
Yes, even in less obvious cases. When an exception occurs, *all* pending
finally blocks execute, in *all* subroutines on the call stack.
"Pending" here means those try-finally blocks, which had been entered
before the subroutine call, but have not alreday been left. This *stack
unwinding* proceeds until the top level subroutine, or until the
exception is caught by an try-except block. The exception handler (in
this except block) resets the exception, so that from this point on
execution proceeds as usual.
The major difference between try-finally and try-except is that
"finally" code executes *always*, regardless of how the try-finally
block is left. The "except" code instead is executed *only* after an
exception occured, not during normal execution. When an exception
handler does *not* handle the current exception type, or re-raises the
exception, or raises another exception, stack unwinding continues until
the next enclosing try-except block.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
