mark wrote:
consider:
Int64 steps = 0;
public Int64 recurse(double A)
{
steps += 1;
A = A/2;
try
{
A = recurse(A);
}
catch
{
return steps;
}
return 1; //To satisfy return on all code paths (never
reached). }
At the point of underflow I would expect a stack overflow exception to
trigger the directive in the catch block. But it does not. Rather, it
If you want you detect underflow, best put "A = A/2;" in a checked block.
Or test if ((A/2)*2 == A).
But in any case I don't think you understand exception handling, based on
your comment on the return statement. Assuming that a catchable exception
is thrown, the next outer stack frame will catch it and execute "return
steps;" thereby returning normally. Thus the next outer frame will finish
the try block without exception, and hit the "never reached" return 1
statement, also returning normally. It is trivial to show by induction (you
did say math question) that any deeper number of calls will also ultimately
return 1. The key point is that the exception is caught by the innermost
enclosing (matching) exception handler, is does not jump to the outermost
frame of the recursion.
Perhaps you meant the catch block to say "return recurse(A);"? In that case
the "return 1;" outside the block would indeed be unreachable and could be
removed.
halts execution in the try block with: "An unhandled exception of type
'System.StackOverflowException' occurred".
Stipulating that a recursive procedure be used, and stipulating that
testing to the known underflow threshold not be performed, how can
this implementation be made functional?