(Probably) New bug found in HP-71B (2CDCC and possibly others)

[J-F Garnier]

This is an interesting test case.

I agree it is no directly related to the bug 1072.
The bug 1072 is related to an error in the FOR statement itself, not in the statements between FOR and NEXT. For instance:
10 ! bug 1072-8
20 ON ERROR GOTO 60
30 FOR J=1 TO 3
40 FOR I=1 TO SQRT(-9)
50 NEXT I
60 PRINT I;J
70 NEXT J
80 END
On the HP71 1BBBB, the outer loop (J) doesn't run well and the program falls into an endless loop :
1 1
1 1
1 1
...

On the HP71 2CDCC, the program just runs fine:
1 1
1 2
1 3

The problem Valentin highlighted seems to be more related to the GOTO jumping out of DEF FN, as can be demonstrated with this small piece of code:
10 ! GOTO jumping out of DEF FN
20 DEF FNF(N)
30 GOTO 70
40 END DEF
50 FOR I=1 TO 3
60 X=FNF(1)
70 DISP I
80 NEXT I
90 END
An error 43 "NEXT w/o FOR" is generated at line 80.
This is consistent with the fact that User-Defined Functions (UDF) have their own FOR-NEXT environment as described in the user manual.

Is it a bug, or just a limitation of the implementation of ON ERROR GOTO ?
I'm not sure, but the HP75 (and probably series 80 as well) have a similar limitation. The generated error is different, but the root cause is the same: it is not allowed to jump out of a DEF FN with a GOTO, either explicitly with a GOTO or implicitly with a ON ERROR GOTO.

A workaround:
Use a ON ERROR GOSUB instead, pointing to a simple RETURN (or setting a global variable to flag the error). The effect will be to ignore errors:
X= 3 , Sqrt( 3 )= 1.73205080757
X= 2 , Sqrt( 2 )= 1.41421356237
X= 1 , Sqrt( 1 )= 1
X= 0 , Sqrt( 0 )= 0
X=-1 , Sqrt(-1 )= 0
X=-2 , Sqrt(-2 )= 0
Done.

J-F