phil mcguinness

Mike,

snip[ Does anyone know of a workaround or patch for this problem? ]

What we do is have a SherlockErrorHandler() and in this .. we trap division
by ZERO
We have done this all the way back through our Clipper applications as well.

PROCEDURE ERRORSYS() AS VOID PASCAL _INIT2
//d Replaced the VO standard errorhandling with our errorhandler
ErrorBlock( {|oError| SherlockErrorHandler(oError)} ) // Routing to our
ErrorHandler

RETURN

------------ snip -----------
// 5
IF (oError:GenCode == EG_ZERODIV )
RETURN 0
ENDIF

--
Phil McGuinness - Sherlock Software

mike jones

Phil,

Yeah, that's pretty much what ours is doing. Have you encountered any
dynamic memory problems as a result of this code being executed in 2.5b3 or
2.6?

Mike

phil mcguinness

snip[ dynamic memory problems ]

Nah... but hopefully I have NO division by zero errors to process. <G>

Phil McGuinness - Sherlock Software
---

mike jones

Phil,

You can check whether this problem exists with this simple test program,
using the standard error handler:

FUNCTION Start

LOCAL result AS FLOAT
LOCAL fred AS ARRAY
LOCAL i AS DWORD

BEGIN SEQUENCE

result := 3.2/0.0

END SEQUENCE

FOR i := 1 UPTO 1000
CollectForced()
fred := ArrayCreate(50000)
? DynInfoSize()
NEXT

Run this program twice. On the first run hit "Cancel" when the error box
pops up as a result of the divide by zero. The error handler will break and
the program resumes after the end sequence. You will see that the dynamic
memory remains constant each time through the loop. On the second run, hit
"Ignore" when the error box appears. This causes the error handler to return
0 which is assigned to the result variable. Now on each loop the dynamic
memory usage increases until the program crashes. i.e. returning from the
error handler without breaking seems to have broken the garbage collector.

Mike