ActiveSupport’s #try might not be doing what you think it’s doing

Today I had reason to verify the exact semantics of ActiveSupport’s Object#try extension for an upcoming RubyTapas episode. #try is usually used to paper over nil values. Unfortunately, #try does more than this, and as a result it can easily hide defects.

Consider: we have a variable with a number in it. We want to round the number down.

Something that sometimes happens in our applications is that we take in some numeric information in string form, and forget to convert it to a number before using it as one. This is a bug that we need to be aware of, and Ruby is more than happy to let us know with an exception.

Now let’s say we know that the value of num is sometimes nil . Rather than removing this nil incursion from our code, we decide to turn the nil case into a harmless no-op with .try .

Remember the previous example, where we got a string and forgot to turn it into a number, and Ruby told us all about it? Guess what happens now:

Congratulations: we now have a silent defect. Good luck finding it in the absence of a NoMethodError .

Why? Because #try doesn’t actually care about nils. It’s only concerned with whether an object responds to the given message. This is consistent with the method’s name. In my experience, though, it is not consistent with what most programmers actually want when they use #try .

Incidentally, Ruby’s recently-added “safe navigation” operator does not share this drawback. It is strictly nil-sensitive.

(I’ll be covering this issue and a whole array of related techniques in an upcoming RubyTapas miniseries.)

UPDATE: A few people have pointed out that at least as of Rails 4.0, there is now a #try! variant with the safer semantics. At the time of writing, this version has yet to make an appearance in the official ActiveSupport Rails Guide.

If you’re using Rails 4 or later, this new version should probably be your default choice.