Try() as you might

Tired of writing things like (user.name if user) and all it's variants?

Almost a year back now, I saw the try() method suggested. The intention of the method is to guard you against calling methods on a nil object. If you try to call a method on a nil object it should return nil, otherwise it should call the method. Here's the implementation:

class Object
  ##
  #   @person ? @person.name : nil
  # vs
  #   @person.try(:name)
  def try(method)
    send method if respond_to? method
  end
end

The implementation is a one liner. Nothing to get excited about, looks simple enough, what could be wrong? And so I've been happily using try's sparsely in my code ever since, and with me I suspect a lot of others, and was a happy camper.

But then today I started to write a few unit tests for that core extension. Hardly looked like it warranted unit tests, but for consistency sake in unit testing my apps core extensions I did it anyways. I created these 4 tests:

test "succeed when trying method" do
  "hello".try(:length).should == 5
end

test "fail when trying method" do
  assert_raises(NoMethodError) { "hello".try(:does_not_exist) }
end

test "not fail when trying method" do
  nil.try(:does_not_exist).should == nil
end

test "return nil when calling any method on nil" do
  nil.try(:to_s).should == nil
end

And so there we had it: 2 out of the 4 tests failed. Excuse me?!

So I took a closer look at this seemingly innocent little method. Apparently there are some pitfalls. For example:

>> "hello".try(:does_not_exist)
=> nil

While I expect nil.try(:does_not_exist) to return nil, I certainly do not expect nil when the receiver object is not nil. I expected a NoMethodError. Obviously, I'd say. How about this one:

>> nil.try(:to_s)
=> ""

I do expect nil.to_s to return an empty string, but not here. The intention is to be guarded against nil, and only if the receiver object is not nil should the method be called.

There is another pitfall, which I haven't created a test for, but something you might want to be aware of. If a class implements methods through a method_missing method then try might not recognize a valid method call because respond_to? will return false, and therefor try will return nil instead of the value that method_missing would return.

All pesky little details, but they could have gnarly consequences.

So I had a look around the internetz, and came across this. Don't like the ability to provide a default, instead of person.try(:name, :default => default) I'd rather do the usual person.try(:name) || default. Do like that you can do user.try(:manager, :name) instead of having to do user.try(:manager).try(:name). My example however immediately points out a flaw in it's implementation: if user.manager returns nil then the receiver object doesn't get changed and in the next iteration of the loop it returns the value of user.name. Easy to fix of course, so let's keep this feature in mind.

Then I came across a few other alternatives that were entertaining the idea of using method_missing, but let's not..

So maybe it's turtles to the rescue! Well, the author considers the code dumb, and I think he's right Still, an entertaining idea.

And so I ended up at the door steps of the Master Guardian of Ruby Land: Ragan Wald. In his last blog post from summer last year he claims he's retired from hacking on Ruby. But nothing is further from the truth. This guy is continuously rethinking how to protect his code with his various slave guards, otherwise known as his little monads doing his dirty washings. He has even come up with some new slaves in the form of Rewrite and a few days ago with RewriteRails. See also his rather obscurely located 'blog post' announcement about this. It does appear like he is on to something very dangerous! Definitely worthwhile to keep an eye on.

Meanwhile, I'm thinking in more simple terms. I just want a very simple implementation of try with no fuss. After downloading more of the internetz I found one other person who argues that the try method isn't doing what it says it's doing. He came up with this instead:

class Object
  ##
  #   @person.name unless @person.nil?
  # vs
  #   @person.try(:name)
  def try(method)
    self.send(method) unless self.nil?
  end
end

Let's run this through the tests, see what happens:

4 tests, 4 assertions, 0 failures, 0 errors

Now that's what I'm talking about! This is the implementation that I'll use. For now. I'll accept the danger that anyone might actually contribute a different try method in some class.

---

UPDATE: And then I read this: And I for one welcome our new insect overlords.

Dear me! The try method has been added to rails 2.3/3.0 last month.

How wrong could I be when just a few minutes ago I wrote, with apparent misplaced confidence, that I'd accept the danger of anyone actually contributing a different try method. They might as well deliver me over to the mad doctor of blood island right now! No point in postponing the horrors that are my fate.

Incidentally, 3 days ago tap has been added to rails as well. But let's stay with try here for the moment. What is it's implementation?

# Tries to send the method only if object responds to it. Return +nil+ otherwise.
# It will also forward any arguments and/or block like Object#send does.
#
# ==== Example :
#
# # Without try
# @person ? @person.name : nil
#
# With try
# @person.try(:name)
#
# # try also accepts arguments/blocks for the method it is trying
# Person.try(:find, 1)
# @people.try(:map) {|p| p.name}
def try(method, *args, &block)
  send(method, *args, &block) if respond_to?(method, true)
end

There you go. Even worse. Allowings arguments and a block, and bypassing the privacy security of your methods! It's like the IRS: they come in whenever they like and they take whatever they like. Sure, ruby is open, so if anyone wanted to break into my object and pry around my private stuff, fine, but do we have to promote that kind of behaviour?

No Mr Horse, I think this should be kidnapped, drugged, and chained deep down a mine shaft behind the bras of any Coober Pedy resident, preferably of those with long dusty zz-top beards.

(disclaimer, before anyone gets upset by my suggestion: I generally do not condone hiding things behind bras. Ever.)

The other issue remains: the example is misleading. Consider this instead:

# # Without try
#  x ? x.to_i : nil
#
# With try
# x.try(:to_i)

When x = 123 you get 123, when x = nil you get 0 with try, nil without try.

Which tests were written? :

class ObjectTryTest < Test::Unit::TestCase
  def setup
    @string = "Hello"
  end

  def test_nonexisting_method
    method = :undefined_method
    assert !@string.respond_to?(method)
    assert_nil @string.try(method)
  end

  def test_valid_method
    assert_equal 5, @string.try(:size)
  end

  def test_valid_private_method
    class << @string
      private :size
    end

    assert_equal 5, @string.try(:size)
  end

  def test_argument_forwarding
    assert_equal 'Hey', @string.try(:sub, 'llo', 'y')
  end

  def test_block_forwarding
    assert_equal 'Hey', @string.try(:sub, 'llo') { |match| 'y' }
  end
end

Okay, so again, why would anyone want to try an :undefined_method on a non-nil receiver? Doesn't make sense to me.

And for what purpose did the rails team add this try method? :

Clearly none whatsoever. Throughout the thousands of lines of code of rails it's used exactly once. No arguments, no block usage. So what's the point? Where's the value? Why do we get this?

I'd consider the reddit possibly more useful.