I don't think this is related to #doesNotUnderstand:, but if you tell me what test case this is I can have a look.
Lukas On Saturday, April 11, 2009, Stéphane Ducasse <[email protected]> wrote: > > On Apr 10, 2009, at 8:41 PM, Lukas Renggli wrote: > > > is it normal that when one doubleclick on an yellow item in the list > it does not open a debugger? > > > No, that's not normal. > > Right now I can think of two possible causes: > > - The test is not deterministic or has side effects that cause it to > sometimes fail and sometimes pass. > > > I do not think that this is the case. > I can reproduce the bhevaior run KernelsTests-classes. > > > > - Another reason that I recently noticed is related to exceptions and > how SUnit runs the tests. When a test is run (when you click on run) > the code is wrapped into an [ ... ] on: Error do: ..., thus catching > all exceptions. When a test is debugged (when you click on an item on > the list) the code is not wrapped in such a handler assuming that this > would cause the system to open a debugger. However, depending on the > exception raised this causes a custom default action to be evaluated > and the test does not fail anymore. Many file-related exceptions have > such a default behavior. Oscar recently reported an issue on this: > <http://code.google.com/p/pharo/issues/detail?id=698>. I wonder why > this only appeared now? Was there anything changed related to SUnit or > Exceptions? > > > I know that we introduce a fix of eliot in the way does not understand > lead to open the debugger. > > see the mail below > The code is attached to a mail of 20 of december in pharo mailing-list > Let me know if you understand better than me. Now I do not have the time > to look at it. > > Stef > > > > Begin forwarded message: > > > From: "Eliot Miranda" <[email protected]> > Date: December 19, 2008 7:52:21 PM CEST > To: "The general-purpose Squeak developers list" > <[email protected]> > Subject: Re: [squeak-dev] Re: Resume Problems > Reply-To: The general-purpose Squeak developers list > <[email protected]> > > Hi Zulq, > > I made sure this was fixed in VisualWorks. Steve Dahl and I fixed this > together. Here's an analogous fix for Squeak. The essential change is to > make Object>>doesNotUnderstand: check if the MessageNotUnderstood exception > was handled or not, so > > MessageNotUnderstood new > message: aMessage; > receiver: self; > signal. > ^ aMessage sentTo: self. > > is replaced with > > (exception := MessageNotUnderstood new) > message: aMessage; > receiver: self. > resumeValue := exception signal. > ^exception reachedDefaultHandler > ifTrue: [aMessage sentTo: self] > ifFalse: [resumeValue] > > HTH > > On Fri, Dec 19, 2008 at 8:13 AM, Zulq Alam <[email protected]> wrote: > Hi Klaus, > > > Klaus D. Witzel wrote: > Nah, the result has nothing to do with #on:do: resuming with 1, you better > try > > [('abc' + 1) + 1] > on: MessageNotUnderstood > do: [:e | e resume: -1] > > which still says 2. This because someone, behind you back, put #asNumber > arithmethic into ByteString ... now this attempts (Number readFrom: 'abc') > which gives 0 for your +1 +1 and so 2. > > You may want to start DNU testing with ('abc' break; + 1) and then see > where it goes. > > Hmm... I think something is not right or at the very least the semantics are > subtly different than I expect. > > VisualWorks: > [Object new blah + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > [MessageNotUnderstood signal + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > Squeak: > [Object new blah + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " infinite recursion!!! " > > [MessageNotUnderstood signal + 1] > on: MessageNotUnderstood > do: [:e | e resume: 1] " = 2 " > > > If I look at doesNotUnderstand: in both I see that in VW the resumed value is > returned. In Squeak is is not... surely this can't be right? > > As for my problem, I think a simpler solution is to pass an adaptor/proxy > object to the block rather than the tag itself. This adaptor can then marshal > behaviour such that it will act as a message eating null if it receives an > MNU from the tag it's looking after. > > Thanks, > Zulq. > > > > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
