[deadbadger]

But then don't you have to make your choice about whether no-value is an error when you return the value, rather than when you make the call?

With #try et al it's made obvious at the point the message is sent whether it'll be swallowed by nil (and that you're fine with this). To me this seems safer than having two classes of entities knocking round, one swallowing messages and one not, and no way to tell at a glance which is which.

(I've not used Smalltalk btw, so apologies if I've misunderstood...)

[gecko]

You can use it either way. I usually employ it at return time, because usually there are classes (little-case C) of return types that I'm fine with being ignored. A list of objects that need to be signaled on an event, for example: it's fine with me if that's not initialized, so it's okay to return null there.

Sometimes, you want to do what you're saying, and have a brief snippet where you switch to message-eating null. That's easy enough using the built-in ifNil: message:

    (foo ifNil: [ null ]) baz quux frob: bar.

If this is common, it'd be easy to add a method "try" to Object that returned self, and one to UndefinedObject that returned null, at which point you could do the same thing as Ruby:

    foo try baz quux frob: bar.

So either way, really.