Problem with ZeroDivide>>resume: ?

Consider the following code:

    ([(2 / 0) * 3] on: ZeroDivide do: [:ex | ex return: ex dividend]) = 2
"verify that #dividend gives what we expect"
    ([(2 / 0) * 3] on: ZeroDivide do: [:ex | ex resume: 2]) = 6  "verify
that #resume: does what we want"
    ([(2 / 0) * 3] on: ZeroDivide do: [:ex | ex resume: ex dividend]) = 6
"now put them together!"

I would expect each of these to return true, but the third fails (and I
offer them as possible test cases). These lines behave as I expect in VW.

James Foster

James Foster wrote:

> I would expect each of these to return true, but the third fails (and I
> offer them as possible test cases). These lines behave as I expect in VW.

I /think/ there are two things going wrong here.

One is that your ZeroDivide hander is getting called twice.  The first time by
the VM as the result of the primitive #/ operation.  That passes 2 as the
#dividend correctly.  The problem is that the result of that is then apparently
ignored (I presume that the primitive is considered to fail) and the fallback
implementation of SmallInteger>>/ is invoked.  That will in turn discover that
you are attempting a zero-divide and invoke your handler a second time, which I
suspect is not the intended behaviour.

The second problem is that the fallback implementation of / ends up in the
equivalent of:

    Fraction rationalisedNumerator: 2 denominator: 0.

If you trace into that expression, you'll see that normalises the denominator
and numerator before invoking the code that will actually detect the
zero-divide.  Since

    2  gcd: 0

answers 2, the arguments to the original #/ are effectively divided by 2 before
the exception is triggered.  Hence, in that case, the #dividend is 1.  So the
second invocation of your exception handler will #resume: (again) with a value
of 1 -- hence the incorrect behaviour.

I think that a partial solution would be for Fraction
class>>rationalisedNumerator:denominator: to do a test for zero before
normalising, but that wouldn't solve the problem (assuming it /is/ a problem)
of the handler's first invocation being ignored.

FWIW, both problems are present in D6 beta 1.

    -- chris

Andy/Blair,

Do you agree that this is a bug? If so, is anything more needed for a bug
report (I've provided sample tests)?

James Foster


"James Foster" <[hidden email]> wrote in message
news:42edac22$[hidden email]...

Andy or Blair,

Can you confirm that this is recorded as a bug?

James Foster


On 31 July 2005, "James Foster" <[hidden email]> wrote in message
news:42edac22$[hidden email]...

"James Foster" <[hidden email]> wrote in message
news:4300e520$[hidden email]...
> Andy or Blair,
>
> Can you confirm that this is recorded as a bug?
>

James, it certainly looks like a bug to me. It will go on the list (as
#1878), but I cannot promise that this will be fixed in time for the D6
release.

Regards

Blair