Skip to content
Browse files

Added Object#try. ( Taken from ) [Chri…

…s Wanstrath]
  • Loading branch information...
1 parent 51a19ae commit 51730792ca930a896361eb92354a42bc56903de1 @lifo lifo committed
2 activesupport/CHANGELOG
@@ -1,5 +1,7 @@
*2.3.0 [Edge]*
+* Added Object#try. ( Taken from ) [Chris Wanstrath]
* Added Enumerable#none? to check that none of the elements match the block #1408 [Damian Janowski]
* TimeZone offset tests: use current_period, to ensure TimeZone#utc_offset is up-to-date [Geoff Buesing]
13 activesupport/lib/active_support/core_ext/object/misc.rb
@@ -71,4 +71,17 @@ def with_options(options)
def acts_like?(duck)
respond_to? "acts_like_#{duck}?"
+ # Tries to send the method only if object responds to it. Return +nil+ otherwise.
+ #
+ # ==== Example :
+ #
+ # # Without try
+ # @person ? : nil
+ #
+ # With try
+ # @person.try(:name)
+ def try(method)
+ send(method) if respond_to?(method, true)

noticed a problem.

>> “some string”.try(:gsub, “some”, “this”) => “this string”

>> nil.try(:gsub, “some”, “this”) => TypeError: $_ value need to be String (nil given) from (irb):18:in `gsub’ from (irb):18:in `send’ from (irb):18 from :0

This is because nil defines a private method “gsub”. Is there really a need for “try” to “try” private methods? It seems like a less useful case than someone using gsub against an accidental nil.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ end
25 activesupport/test/core_ext/object_and_class_ext_test.rb
@@ -247,3 +247,28 @@ def test_instance_exec_nested
[arg] + instance_exec('bar') { |v| [reverse, v] } }
+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

27 comments on commit 5173079

Ruby on Rails member

I like the functionality, but the name doesn’t quite “click” to me either.

Bang methods have different semantics… what about “send?”. Oh, the signature could accept args as well.




‘send?’ would be nice.


take a look at .andand though renaming it ._? might be nicer # almost equivalent to groovy’s object.?.method


+1 for send?


How about `attempt?`? Try reminds me of `try… catch`



+1 for “send?”.


I like the name try, though I prefer a version that allows arguments and/or a block:


Try is fine by me, but +1 for nakajima’s patch.


I particularly like the use of the symbol :wee in his examples.


why not use a proxy so you could just do string.try.size ?


-5 for send?. Foo? methods, by convention, return boolean values. Try does not.


+1 nakajima


josegit: That’s usually the case, but not always. To quote matz from a recent ruby-talk thread:

By convention, they are predicates, which means the return value can be considered as boolean value. But at the same time, the values are not limited to true and false. For example, defined? returns the string to describe the kind of expression defined, and nil otherwise.

There’s another convention that when a predicate returns non-true value for represent true, it should return nil for false.

Then again, whether this is a predicate can be discussed. I think I’ll retract my +1 for a ±0.


Mangled by textile. First and last paragraphs are mine, middle two are quoted from matz.


A better example may be Ruby’s Numeric#nonzero? which returns the number if it’s not zero and returns nil otherwise. send? would be pretty analogous.


I’ll let others hash out the appropriate method name, but I agree that it should at least support arguments like #send.

Ruby on Rails member

Please submit patches at Lighthouse and assign to me.



this is nice sugar.


Sumitted patch with Nakajima’s suggestion:


Submitted a patch based on alloy’s, adding the option of doing person.try_name(arg1, arg2, …) { … }


Thank you very-very much. I think it will be very useful!


Surely with nakajima’s version it should be called do_or_do_not – remember “there is no try”…


The problem is nil.respond_to?(:id) is true. and so you can’t use it as for


vitaly: That’s an instance in which you’d probably want to rethink using #try anyway, and instead perhaps structure your interface in such a way that doesn’t return nil objects.

I know it’s ridiculous for me to say this, since I was the one who recommended an “improved” version, but I actually think that nine times out of ten, using #try is a code smell.


+1 nakajima

Ruby on Rails member

nakajima suggestion is already into core:

Please sign in to comment.
Something went wrong with that request. Please try again.