Bug #9083: BasicObject#method_missing does not always raise NoMethodError for missing methods

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.0.0p247 (2013-06-27 revision 41674) [i686-linux]

[rits (First Last)]

def method_missing(name, *)
super
rescue NoMethodError => e

end

if the method is called without the receiver, it will raise just a NameError (variable or method missing)

the text of the error can differ depending on the presence of the receiver, but it seems counter-intuitive to not receive a NoMethodError when you are clearly attempting to call a non-existent method.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Closed
• Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN)

NoMethodError is a subclass of NameError. I think what you are running into is:

BasicObject.new.foo # NoMethodError
BasicObject.new.instance_exec{foo} # NameError

In both of these cases, BasicObject#method_missing is called, but that method has some magic to determine which error to raise. This behavior in both cases is expected, because the foo in the second case would be a local variable reference if there was a local variable reference in scope. Ruby does not know whether your intention was to reference a local variable or call a method, and therefore uses the more generic NameError instead of the more specific NoMethodError in that case. In the first case, the foo is definitely a method call and not a local variable reference, so Ruby can use a more specific error.