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 ignore

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.