Concerning the bug 22085, i commented on fogbuzz: > I believe it is because when running test cases, it runs through: > > runCaseForDebug: aTestCase > [...call test code...] > on: self class failure , self class skip, self class warning, self class error > do: [:ex | ex sunitAnnounce: aTestCase toResult: self. ex pass] > > So when you reach a doesNotUnderstand, you have: > > doesNotUnderstand: aMessage > [...stuff...] > > resumeValue := exception signal. > > ^exception reachedDefaultHandler > ifTrue: [aMessage sentTo: self] > ifFalse: [resumeValue] > > In normal cases (class of the receiver is not a test case), when you step in > the debugger the exception signal blocks the execution right away. In > subclasses of TestCase, it does ex pass each time you get to this line, then > it enters the aMessage sentTo: self, which is not understood, then you can > wait a long time... > > It is equivalent to doing this in a playground: > > [ Object new doStuff ] on: Exception do:[:ex| ex pass] > > Then step in the debugger and bye bye. But then it seems to be expected > behavior... or maybe not ? I mean voluntarily passing on an exception in a > doesNotUnderstand would lead to such problems.
I have heard at least three different stories about this bug : yours, the one from fogbuzz and one other a bit different from Guille. They seem to be different but all of them end up looping ad vitam eternam after a debugger step. I am looking for ways to reproduce any of this bugs (well except 22085), but so far i have no success on my own images :'( (pharo 6.1 & 7). Steven.
