The sketch is attached as requested, however from the broken image, if I save the sketch, close it and reopen it, then the problem goes away.
So it seems the error is more intrinsic to the GUI, and only exists in the image I previously linked to.

btw, The immediate naive fix would be to replace to #do: with #ifNotNilDo:

Hilaire Fernandes wrote:
Ben,

Can you send me a saved sketch producing the error (not the whole
image), I would like to see track and register the error on the bug tracler.

Hilaire


Le 24/10/2011 15:56, Ben Coman a écrit :
  
Thanks for your comment Bill.  I need to learn more about good exception
handling for my own applications.
What I was surprised about was that nil appeared to receive a #do: but
not raise an error, and that next step in execution was
OrderedCollection>>do: . Anyway, saving the sketch, closing the image,
and the next day opening the sketch has cleared the error.

Ben

Schwab,Wilhelm K wrote:
    
Ben,

I can't comment on the workings of Dr. Geo, but since you ask about
#do:, nil, least surprise etc., I can tell you that errors are your
friends.  Note that there is a difference between sending #do: to nil
(would you really expect "nothing" to know how to iterate its
contents?) and sending #do: to a collection that contains elements,
some of which happen to be nil?  In the latter case, would it really
be non-surprising to have nil elements treated differently from their
peers?  Would you have them treated differently only if nil encounters
a problem doing what is asked of it?  In that case, #do: would have to
trap and suppress errors, at least for nil entries.

All of that sounds pretty surprising to me.  Eventually, it will to
you too.  Happy Smalltalking!

Bill



________________________________________
From:
pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr]
On Behalf Of Ben Coman [btc@openInWorld.com]
Sent: Saturday, October 22, 2011 2:36 PM
To: Pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project]
[BUG]UndefinedObject(Object)>>doesNotUnderstand:       #update

I was using DrGeo for the first time from the bundled release 11.08 on
Windows 7.  About 30 minutes in I drew three equally intersecting
circles, added a reflection line with each circle reflected.  I added a
free point with a middle (I think to a circle) and was trying to add a
locus.

When moving any of the points defining the circles I am getting a dozen
or more cascading MNUs down the screen.  Moving the reflection line
still works okay.

The error occurs in following method...
DrGeo>>updateDirtyCostumes
    self presenter tool costumes do: [ :each | each update ].
    self area changed

In the debugger inspecting "self presenter tool costumes" returns nil.
While I can't judge whether returning nil is valid here, as a Smalltalk
newbie what I am really interested in is:

1. The semantics of sending a "do:" message to nil.  By the principle of
least surprise I would expect that it would do ...nothing, whereas here
it tries later sending the "update" method to it.

2. Why in lines 0027 and 0641 is the "do:" method received by
OrderedCollection and not UndefinedObject? Actually I can't see "do:" in
the hierarchy of UndefinedObject, so why does UndefinedObject not raise
a MNU for "do:" ?

The image with the error is available at...
http://blog.openinworld.com/miscfiles/DrGeo-updateDirtyCostumes-MNU-2011-10-22-btc.zip


The stack trace generated by the <Mail out bug report> menu item is
below. I wasn't sure how much of it to cut or leave, so I've left it all.
------------------8<-------------------------
00000001 22 October 2011 10:27:03 pm
00000002
00000003 VM: Win32 - IX86 - NT - Squeak3.10.2 of 11 February 2010
[latest update: #9314]