Marcel Weiher wrote:

> 
> 
>> But, since the only "classic Smalltalk" solution is to make "black-hole"
>> messaging system/image wide, then it becomes quite troubling when any
>> thought is given to teams of people integrating code which may come from
>> unrelated parties and their distinct frameworks.
> 
> 
> I don't see any validation for your claim that this becomes troubling.  
> None whatsoever.  I just have evidence to the contrary.
> 
> Marcel
> 


It's difficult to integrate other people's code when the "other" people 
write code like this:

    [foo bar someMessage]
       on: MessageNotUnderstood
       do: [:ex | foo fum].

And, that kind of code is actually quite common to see.

In this case, if #bar returned a message-eating nil, then the #fum 
method never executes, and the application probably expected it to. 
That's one of the problems with introducing message-eating nils into the 
existing code base.

With message-eating nil behavior, the above could have been written thus:

    foo bar someMessage isNil ifTrue: [foo fum].

...which interestingly enough once again is simpler than the original code.

If it weren't for the need to adopt the pattern layer-wide and 
uniformly, I too am convinced there is nothing wrong with the pattern, 
and firmly side with Marcel.

It's when the pattern has to co-exist with code written by people who 
expected the other (exception throwing nil) behavior where it gets into 
trouble.

Nevin