Re: Pop Quiz: Raising an exception inside a function in relation to the return values.


"Maarten Wiltink" <maarten@xxxxxxxxxxxxxxxxxx> wrote in message
news:468d5b22$0$322$e4fe514c@xxxxxxxxxxxxxxxxx
"Skybuck Flying" <spam@xxxxxxxxxxx> wrote in message
news:f6jeo9$jbg$1@xxxxxxxxxxxxxxxxxxxxxxxxxx

(Moved the code to the top)

uses SysUtils;

function Test : integer;
begin
result := 666;
Raise Exception.Create('You crazy');
result := 111;
end;

var A : integer;
begin
A := 333;
try
A := Test;
except
end;
writeln( A );
readln;
end.
[...]
Can you answer these questions purely based on the help file ?

No, because I already know too much. But let's pretend.


[...]
Pop Quiz:

1. What does Test return ?

A. 0
B. 666
C. 111
D. nothing
E. garbage

Contaminated by C and its void non-type, I want to say 'none of the
above'. It's not so much that Test returns 'nothing' (I'd want it to
be a procedure then), it's that it does not return anything - this
time around. (If the exception were raised if (Random<0.50), what
would you say?)

Ok fun answer.

The question isn't correct lol.

The correct answer is:

F. Test does not return, test is aborted, test is jumped out by the raising
of the exception.



2. Which hint is generated ?

A. result 111 code never reached.
B. value assigned to test never used.
C. return value of test undefined.
D. no hints.

A and B are logically equivalent.

No, I don't agree with that.

Simply pretend the raise is a return and you ll see the difference.

C is manifestly not the case, three
times over.

Ok I'll change C to:

C. return value of test unknown at runtime.

(It is known temporarely isn't it ? unless it's optimized away)

My guess is D, which is also consistent with my experience.
The compiler could do much better flow analysis in the face of
exceptions.

Delphi 2007 proceduces answer B.

3. Which value is finally displayed ?

A. 0
B. 111
C. 333
D. 666
E. garbage

C. No second assignment ever happens.

Indeed.

Try to answer these questions by looking in the help.
My point: It's not documented ? or I can't find it ?

I think I actually understand and appreciate your problem with
exceptions. The key is that they _replace_ the normal flow of logic.
Effectively, there are two linear programs woven together in a single
source file, and execution can skip from one to the other and back.
Fortunately, there is method to the madness. Raise statements switch
to the exception handling strain; try-except statements switch back
(at the end) to normal execution.

The exception was raised after 666 was assigned to the result.

So according to your reasoning 666 would have to be returned.

However that never happens.

Now that I look at it again it seems kinda logical.

The assignement:

A := Test;

Is never completed.

A was not assigned anything.

A remains 333.

(
However I like to think of result as being a reference to A.

So when changing the result I like to think A is immediatly change as
well...
)

I'll guess I'll have to start thinking of result as a temporarely variable
from now on :)

Bye,
Skybuck.


.

Relevant Pages