The 28 Bytes of Ruby Joy will notably clean up your code:

28_bytes_of_ruby_joy 1 def p.method_missing*_ ; p ; end

All it does is patching the nil object that it also returns nil when you call an unknown method on it. Normally it would raise a NoMethodError . This is the cleaner, non-golfed version:

silent_nil 1 2 3 4 5 class NilClass def method_missing * _ nil end end

Consider the following, common situation: You have an instance variable, which usually contains a hash of objects: @some_hash . Now you want to access :some_key and want to do something with the value. You also know, @some_hash is sometimes nil . So you might want to write

if @some_hash[:some_key] # good looking version # do something with @some_hash[:some_key] end

but it is not working properly, because it fails on when @some_hash is nil . Instead, you have to write

if @some_hash && @some_hash[:some_key] # correct version # do something with @some_hash[:some_key] end

And this is just an easy example. Let’s take a look at

if @some_hash[:some_key].to_formatted_array[3] # good looking version # do something end

vs

if @some_hash && some_hash[:some_key] && @some_hash[:some_key].to_formatted_array && @some_hash[:some_key].to_formatted_array[3] # correct version # do something end

The 28 Bytes of Ruby Joy allow you to do use the good looking version in both examples.

Conclusions

A drawback of the hack might be, that the application does not crash at some occasions, where it probably should do so, but forwards the nil . But I think, in reality, this means just a few more tests.

The primary reason, I dislike the exception raising of nil is that it creates some kind of redundancy. I do not want to double-check if something is nil . And to say it with the words of Yukihiro Matsumoto himself: “When information is duplicated, the cost of maintaining consistency can be quite high.”

So, what is a strong counter-argument for not using the 28 Bytes of Ruby Joy?

Update

After reading some feedback, I have realised, that I need to add this disclaimer: Don’t just use this hack, if you don’t see all of its consequences – especially when used together with already existing code that assumes the usual nil exception way (like Ruby on Rails).

However, if you do fully understand it, it might be a nice help on your own projects (maybe in a more decent form).

Here are some more resources about (and arguments against) the topic:

Update II

This is a nice snippet by Yohan to decently activate this feature when needed.

catch_nil 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 def catch_nil (& block ) ori_method_missing = NilClass . instance_method ( :method_missing ) catch_method_missing = NilClass . instance_method ( :catch_method_missing ) NilClass . send :define_method , :method_missing , catch_method_missing yield ensure NilClass . send :define_method , :method_missing , ori_method_missing end class NilClass def catch_method_missing ( m , * args , & block ) nil end end

Update III

This version does not use method_missing and allows a default value (but with different semantics: after the raise, no more code gets executed).

egonil_variant 1 2 3 4 5 6 7 8 9 def egonil ( nil _value = nil ) yield rescue NoMethodError => e if e . message =~ / NilClass$ / nil _value else raise NoMethodError end end

Update IV

To use the egonil in daily coding, you can use the zucker gem.

Update V