> So why not just wrap the call to #dropMorph:event: in an exception 
> handler that just deletes the morph on an exception?
> 
> Something like:

Try it ;-) The use case is to make a faulty #wantsDroppedMorph: and
#wantsToBeDroppedInto: method. If you find something that is simpler than
just throwing the morph away in order to be able to both, continue to run
your system and look at the code that's broke in the debugger, I'm all ears.
Dropping the guy before trouble can potentially start is just TSTCPW - and
it works very well.

> > BTW, on an even larger scale I think that drag and drop shouldn't
> > even be done by adding some morph "physically" to the hand.
[...]
> 
> I'm doing something like that in Connectors during (the second half 
> of) wiring.
> 
> A new, invisible Connector is grabbed by the hand.
> 
> When it's dropped, it becomes visible and its second end starts 
> following the hand.
> 
> Then when the next mouse event happens (up or down), it stops 
> following the hand.

Right. That (the second part) is just what should be happening for every
drag operations. Besides being more robust and making clear what "the hand"
visually means (the mouse cursor) it also allows for some quite interesting
optimizations in terms of drag caching (e.g., using direct screen blts as
the morph is no longer hanging in thin air but solidly standing in the world
;-)

Cheers,
  - Andreas